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Revision Log - Version 4.3 


The following changes have been made to Book 4 since the publication of 
Version 4.2. Numbering and cross references in this version have been updated to 
reflect changes introduced by the published bulletins. 


Incorporated changes described in the following Specification Updates: 


Specification Update Bulletin no. 70 Third Edition: Selectable Kernel 
Configurations 


Specification Update Bulletin no. 71 Second Edition: Change the status of 
the ‘Presence’ of the Application Label data element in the FCI of an ADF 
to mandatory 


Specification Update Bulletin no. 72: DDA support in terminals 


Incorporated changes described in the following Specification Bulletins: 
Specification Bulletin no. 76: Language Selection 
Specification Bulletin no. 78: Removal of DDF Entries from PSE Records 
Specification Bulletin no. 79: Amount Requested in the PDOL 
Specification Bulletin no. 82: Various Terminal Updates 
Specification Bulletin no. 85: CVM Results after a CVM Failure 
Specification Bulletin no. 88: Application Selection Updates 


Minor editorial clarifications, including those described in the following 
Specification Bulletin: 


Specification Bulletin no. 80: Editorial Errors in Version 4.2 of the EMV 
Specifications 
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1 Scope 


This document, the Integrated Circuit Card Specifications for Payment Systems - 
Book 4, Cardholder, Attendant, and Acquirer Interface Requirements for Payment 
Systems, defines the mandatory, recommended, and optional terminal 
requirements necessary to support the acceptance of integrated circuit cards 
(ICCs) in accordance with the other documents of the Integrated Circuit Card 
Specifications for Payment Systems, all available on http://www.emvco.com: 


e Book 1 - Application Independent ICC to Terminal Interface Requirements 
e Book 2 - Security and Key Management 
e Book 3 - Application Specification 


1.1 Changes in Version 4.3 


This release incorporates all relevant Specification Update Bulletins, Application 
Notes, amendments, etc. published up to the date of this release. 


The Revision Log at the beginning of the Book provides additional detail about 
changes to this specification. 


1.2 Structure 


Book 4 consists of the following parts: 


Part I - General 

Part II - General Requirements 

Part III - Software Architecture 

PartIV - Cardholder, Attendant, and Acquirer Interface 
Part V - Annexes 


Part I includes this introduction, as well as data applicable to all Books: 
normative references, definitions, abbreviations, notations, data element format 
convention, and terminology. 


Part II addresses: 


e Functional requirements, such as those emerging from the other Books of the 
Integrated Circuit Card Specifications for Payment Systems 


e General physical characteristics 
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Part III addresses software architecture including software and data 
management. 


Part IV discusses: 
e Cardholder and attendant interface 
e Acquirer interface 


Part V discusses the coding of terminal data elements, lists the common 


character set, provides an example data element conversion, includes informative 


terminal guidelines, and provides examples of the physical and functional 
characteristics of terminals. 


The Book also includes a revision log and an index. 


This specification applies to all terminals operating in attended or unattended 
environments, having offline or online capabilities, and supporting transaction 
types such as purchase of goods, services, and cash. Terminals include but are 
not limited to automated teller machines (ATMs), branch terminals, 
cardholder-activated terminals, electronic cash registers, personal computers, 
and point of service (POS) terminals. 


This specification defines the requirements necessary to support the 
implementation of ICCs. These requirements are in addition to those already 
defined by individual payment systems and acquirers for terminals that accept 
magnetic stripe cards. ICC and magnetic stripe acceptance capability may 
co-exist in the same terminal. 


It is recognised that different terminal implementations exist depending on 
business environment and intended usage. This specification defines 
requirements for those features and functions that are applicable according to 
the particular operating environment of the terminal. 


This specification: 


e Does not cover application-specific terminal requirements unique to individual 


payment systems and those functions not required to support interchange. 


e Does not address cardholder or merchant operating procedures, which are 
established by individual payment systems. 


e Does not provide sufficient detail to be used as a specification for terminal 
procurement. 


Individual payment systems and acquirers will define complementary 
requirements applicable to different situations that will provide more detailed 
specifications applicable to terminal implementations. 
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1.3 Underlying Standards 


This specification is based on the ISO/IEC 7816 series of standards and should be 
read in conjunction with those standards. However, if any of the provisions or 
definitions in this specification differ from those standards, the provisions herein 
shall take precedence. 


1.4 Audience 


This specification is intended for use by manufacturers of ICCs and terminals, 
system designers in payment systems, and financial institution staff responsible 
for implementing financial applications in ICCs. 
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2 Normative References 


The following standards contain provisions that are referenced in these 
specifications. The latest version shall apply unless a publication date is 
explicitly stated. 


ISO 639-1 Codes for the representation of names of 
languages — Part 1: Alpha-2 Code 


Note: This standard is updated continuously by ISO. 
Additions/changes to ISO 639-1:1988: Codes for the 
Representation of Names of Languages are available 
on: 

http://www.loc.gov/standards/iso639- 
2/php/code_changes.php 


ISO 3166 Codes for the representation of names of countries 
and their subdivisions 


ISO 4217 Codes for the representation of currencies and 
funds 

ISO/IEC 7811-1 Identification cards — Recording technique — 
Part 1: Embossing 

ISO/IEC 7811-83 Identification cards — Recording technique — 
Part 3: Location of embossed characters on ID-1 
cards 

ISO/IEC 7813 Identification cards — Financial transaction cards 

ISO/IEC 7816-1 Identification cards — Integrated circuit(s) cards 


with contacts — Part 1: Physical characteristics 


ISO/IEC 7816-2 Information technology — Identification cards — 
Integrated circuit(s) cards with contacts — Part 2: 
Dimensions and location of contacts 


ISO/IEC 7816-3 Identification cards — Integrated circuit cards — 
Part 3: Cards with contacts — Electrical interface 
and transmission protocols 
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ISO/IEC 7816-4 


ISO/IEC 7816-5 


ISO/IEC 7816-6 


ISO 8583:1987 


ISO 8583:1993 


ISO/IEC 8825-1 


ISO/IEC 8859 


ISO 9362 


ISO 9564-1:2011 


ISO/IEC 9796-2:2010 


ISO/IEC 9797-1:2011 


ISO/IEC 10116 


ISO/IEC 10118-3 


Identification cards — Integrated circuit cards — 
Part 4: Organization, security and commands for 
interchange 


Identification cards — Integrated circuit cards — 
Part 5: Registration of application providers 


Identification cards — Integrated circuit cards — 
Part 6: Interindustry data elements for 
interchange 


Bank card originated messages — Interchange 
message specifications — Content for financial 
transactions 


Financial transaction card originated messages — 
Interchange message specifications 


Information technology — ASN.1 encoding rules: 
Specification of Basic Encoding Rules (BER), 
Canonical Encoding Rules (CER) and 
Distinguished Encoding Rules (DER) 


Information processing — 8-bit single-byte coded 
graphic character sets 


Banking — Banking telecommunication messages — 
Bank identifier codes 


Financial services — Personal Identification 
Number (PIN) management and security — Part 1: 
Basic principles and requirements for PINs in 
card-based systems 


Information technology — Security techniques — 
Digital signature schemes giving message recovery 
— Part 2: Integer factorization based mechanisms 


Information technology — Security techniques — 
Message Authentication Codes — Part 1: 
Mechanisms using a block cipher 


Information technology — Security techniques — 
Modes of operation for an n-bit block cipher 


Information technology — Security techniques — 
Hash-functions — Part 3: Dedicated hash-functions 
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ISO/IEC 10373 Identification cards — Test methods 

ISO 13491-1 Banking — Secure cryptographic devices (retail) — 
Part 1: Concepts, requirements and evaluation 
methods 

ISO 13616 Banking and related financial services — 


International bank account number (IBAN) 


ISO 16609 Banking — Requirements for message 
authentication using symmetric techniques 


ISO/IEC 18031 Information technology - Security techniques - 
Random bit generation 


ISO/IEC 18033-3 Information technology — Security techniques — 
Encryption algorithms — Part 3: Block ciphers 
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3 Definitions 


The following terms are used in one or more books of these specifications. 


Accelerated 
Revocation 


Application 
Application 
Authentication 


Cryptogram 


Application 
Cryptogram 


Authorisation 
Request Cryptogram 


Authorisation 
Response 
Cryptogram 
Asymmetric 


Cryptographic 
Technique 


Authentication 


Block 


Byte 


A key revocation performed on a date sooner than the 
published key expiry date. 


The application protocol between the card and the 
terminal and its related set of data. 


An Application Cryptogram generated by the card 
when declining a transaction 


A cryptogram generated by the card in response to a 
GENERATE AC command. See also: 


e Application Authentication Cryptogram 
e Authorisation Request Cryptogram 
e Transaction Certificate 


An Application Cryptogram generated by the card 
when requesting online authorisation 


A cryptogram generated by the issuer in response to 
an Authorisation Request Cryptogram. 


A cryptographic technique that uses two related 
transformations, a public transformation (defined by 
the public key) and a private transformation (defined 
by the private key). The two transformations have the 
property that, given the public transformation, it is 
computationally infeasible to derive the private 
transformation. 


The provision of assurance of the claimed identity of 
an entity or of data origin. 


A succession of characters comprising two or three 
fields defined as prologue field, information field, and 
epilogue field. 


8 bits. 
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Card 


Certificate 


Certification 
Authority 
Ciphertext 


Cold Reset 


Combined 
DDA/Application 
Cryptogram 
Generation 


Command 


Compromise 


Concatenation 


Contact 


Cryptogram 


A payment card as defined by a payment system. 


The public key and identity of an entity together with 
some other information, rendered unforgeable by 
signing with the private key of the certification 
authority which issued that certificate. 


Trusted third party that establishes a proof that links 
a public key and other relevant information to its 
owner. 


Enciphered information. 


The reset of the ICC that occurs when the supply 
voltage (VCC) and other signals to the ICC are raised 
from the inactive state and the reset (RST) signal is 
applied. 


A form of offline dynamic data authentication. 


A message sent by the terminal to the ICC that 
initiates an action and solicits a response from the 


ICC. 
The breaching of secrecy or security. 


Two elements are concatenated by appending the bytes 
from the second element to the end of the first. Bytes 
from each element are represented in the resulting 
string in the same sequence in which they were 
presented to the terminal by the ICC, that is, most 
significant byte first. Within each byte bits are ordered 
from most significant bit to least significant. A list of 
elements or objects may be concatenated by 
concatenating the first pair to form a new element, 
using that as the first element to concatenate with the 
next in the list, and so on. 


A conducting element ensuring galvanic continuity 
between integrated circuit(s) and external interfacing 


equipment. 


Result of a cryptographic operation. 
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Cryptographic 
Algorithm 


Data Integrity 
Deactivation 
Sequence 
Decipherment 


Digital Signature 


Dynamic Data 
Authentication 
Embossing 
Encipherment 


Epilogue Field 


Exclusive-OR 


Financial 
Transaction 


Function 


An algorithm that transforms data in order to hide or 
reveal its information content. 


The property that data has not been altered or 
destroyed in an unauthorised manner. 


The deactivation sequence defined in section 6.1.5 of 
Book 1. 


The reversal of a corresponding encipherment. 


An asymmetric cryptographic transformation of data 
that allows the recipient of the data to prove the origin 
and integrity of the data, and protect the sender and 
the recipient of the data against forgery by third 
parties, and the sender against forgery by the 
recipient. 


A form of offline dynamic data authentication 
Characters raised in relief from the front surface of a 
card. 


The reversible transformation of data by a 
cryptographic algorithm to produce ciphertext. 


The final field of a block. It contains the error 
detection code (EDC) byte(s). 


Binary addition with no carry, giving the following 
values: 


0+0=0 
0O+1=1 
1+0=1 
1+1=0 


The act between a cardholder and a merchant or 
acquirer that results in the exchange of goods or 
services against payment. 


A process accomplished by one or more commands and 
resultant actions that are used to perform all or part of 
a transaction. 
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Guardtime 


Hash Function 


Hash Result 


Inactive 


Integrated Circuit 
Module 


Integrated Circuit(s) 
Integrated Circuit(s) 
Card 


Interface Device 


Issuer Action Code 


The minimum time between the trailing edge of the 
parity bit of a character and the leading edge of the 
start bit of the following character sent in the same 
direction. 


A function that maps strings of bits to fixed—length 
strings of bits, satisfying the following two properties: 


e It is computationally infeasible to find for a given 
output an input which maps to this output. 


e It is computationally infeasible to find for a given 
input a second input that maps to the same output. 


Additionally, if the hash function is required to be 
collision—resistant, it must also satisfy the following 
property: 


e It is computationally infeasible to find any two 
distinct inputs that map to the same output. 


The string of bits that is the output of a hash function. 


The supply voltage (VCC) and other signals to the ICC 
are in the inactive state when they are at a potential of 
0.4 V or less with respect to ground (GND). 


The sub-assembly embedded into the ICC comprising 
the IC, the IC carrier, bonding wires, and contacts. 


Electronic component(s) designed to perform 
processing and/or memory functions. 


A card into which one or more integrated circuits are 
inserted to perform processing and memory functions. 


That part of a terminal into which the ICC is inserted, 
including such mechanical and electrical devices as 
may be considered part of it. 


Any of the following, which reflect the issuer-selected 
action to be taken upon analysis of the TVR: 


e Issuer Action Code - Default 
e Issuer Action Code - Denial 
e Issuer Action Code - Online 
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Kernel 


Key 


Key Expiry Date 


Key Introduction 


Key Life Cycle 


Key Replacement 


Key Revocation 


Key Revocation Date 


Key Withdrawal 


Keypad 


The set of functions required to be present on every 
terminal implementing a specific interpreter. The 
kernel contains device drivers, interface routines, 
security and control functions, and the software for 
translating from the virtual machine language to the 
language used by the real machine. In other words, the 
kernel is the implementation of the virtual machine on 
a specific real machine. 


A sequence of symbols that controls the operation of a 
cryptographic transformation. 


The date after which a signature made with a 
particular key is no longer valid. Issuer certificates 
signed by the key must expire on or before this date. 
Keys may be removed from terminals after this date 
has passed. 


The process of generating, distributing, and beginning 
use of a key pair. 


All phases of key management, from planning and 
generation, through revocation, destruction, and 
archiving. 


The simultaneous revocation of a key and introduction 
of a key to replaced the revoked one. 


The key management process of withdrawing a key 
from service and dealing with the legacy of its use. Key 
revocation can be as scheduled or accelerated. 


The date after which no legitimate cards still in use 
should contain certificates signed by this key, and 
therefore the date after which this key can be deleted 
from terminals. For a planned revocation the Key 
Revocation Date is the same as the key expiry date. 


The process of removing a key from service as part of 
its revocation. 


Arrangement of numeric, command, and, where 
required, function and/or alphanumeric keys laid out 
in a specific manner. 
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Library 


Logical Compromise 


Magnetic Stripe 


Message 


Message 
Authentication Code 


Nibble 


Padding 
Path 


Payment System 
Environment 


Physical Compromise 


PIN Pad 


Plaintext 


Planned Revocation 


A set of high—level software functions with a published 
interface, providing general support for terminal 
programs and/or applications. 


The compromise of a key through application of 
improved cryptanalytic techniques, increases in 
computing power, or combination of the two. 


The stripe containing magnetically encoded 
information. 


A string of bytes sent by the terminal to the card or 
vice versa, excluding transmission—control characters. 


A symmetric cryptographic transformation of data that 
protects the sender and the recipient of the data 
against forgery by third parties. 


The four most significant or least significant bits of a 
byte. 


Appending extra bits to either side of a data string. 
Concatenation of file identifiers without delimitation. 


A logical construct within the ICC, the entry point to 
which is a Directory Definition File (DDF) named 
'1IPAY.SYS.DDF01'. This DDF contains a Payment 
System Directory which in turn contains entries for 
one or more Application Definition Files (ADFs) which 
are formatted according to this specification. 


The compromise of a key resulting from the fact that it 
has not been securely guarded, or a hardware security 
module has been stolen or accessed by unauthorised 
persons. 


Arrangement of numeric and command keys to be used 
for personal identification number (PIN) entry. 


Unenciphered information. 


A key revocation performed as scheduled by the 
published key expiry date. 
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Potential 
Compromise 


Private Key 


Prologue Field 


Public Key 


Public Key 
Certificate 


Response 


Script 


Secret Key 


Signal Amplitude 


Signal Perturbations 


Socket 


A condition where cryptanalytic techniques and/or 
computing power has advanced to the point that 
compromise of a key of a certain length is feasible or 
even likely. 


That key of an entity’s asymmetric key pair that 
should only be used by that entity. In the case of a 
digital signature scheme, the private key defines the 
signature function. 


The first field of a block. It contains subfields for node 
address (NAD), protocol control byte (PCB), and length 


(LEN). 


That key of an entity's asymmetric key pair that can 
be made public. In the case of a digital signature 
scheme, the public key defines the verification 
function. 


The public key information of an entity signed by the 
certification authority and thereby rendered 
unforgeable. 


A message returned by the ICC to the terminal after 
the processing of a command message received by the 
ICC. 


A command or a string of commands transmitted by 
the issuer to the terminal for the purpose of being sent 
serially to the ICC as commands. 


A key used with symmetric cryptographic techniques 
and usable only by a set of specified entities. 


The difference between the high and low voltages of a 
signal. 


Abnormalities occurring on a signal during normal 
operation such as undershoot/overshoot, electrical 
noise, ripple, spikes, crosstalk, etc. Random 
perturbations introduced from external sources are 
beyond the scope of this specification. 


An execution vector defined at a particular point in an 
application and assigned a unique number for 
reference. 
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State H 


State L 


Static Data 
Authentication 


Symmetric 
Cryptographic 
Technique 


T=0 


T=1 


Template 


Terminal 


Terminal Action Code 


Terminate Card 
Session 


Terminate 
Transaction 


Voltage high on a signal line. May indicate a logic one 
or logic zero depending on the logic convention used 
with the ICC. 


Voltage low on a signal line. May indicate a logic one 
or logic zero depending on the logic convention used 
with the ICC. 


Offline static data authentication 


A cryptographic technique that uses the same secret 
key for both the originator’s and recipient’s 
transformation. Without knowledge of the secret key, 
it is computationally infeasible to compute either the 
originator’s or the recipient’s transformation. 


Character—oriented asynchronous half duplex 
transmission protocol. 


Block—oriented asynchronous half duplex transmission 
protocol. 


Value field of a constructed data object, defined to give 
a logical grouping of data objects. 


The device used in conjunction with the ICC at the 
point of transaction to perform a financial transaction. 
The terminal incorporates the interface device and 
may also include other components and interfaces such 
as host communications. 


Any of the following, which reflect the 
acquirer-selected action to be taken upon analysis of 
the TVR: 


e Terminal Action Code - Default 
e Terminal Action Code - Denial 
e Terminal Action Code - Online 


End the card session by deactivating the IFD contacts 
according to section 6.1.5 of Book 1, and displaying a 
message indicating that the ICC cannot be used to 
complete the transaction 


Stop the current application and deactivate the card. 
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Transaction An action taken by a terminal at the user’s request. 
For a POS terminal, a transaction might be payment 
for goods, etc. A transaction selects among one or more 
applications as part of its processing flow. 


Transaction An Application Cryptogram generated by the card 
Certificate when accepting a transaction 
Virtual Machine A theoretical microprocessor architecture that forms 


the basis for writing application programs in a specific 
interpreter software implementation. 


Warm Reset The reset that occurs when the reset (RST) signal is 
applied to the ICC while the clock (CLK) and supply 
voltage (VCC) lines are maintained in their active 
state. 
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4 Abbreviations, Notations, Conventions, and 
Terminology 


4.1 Abbreviations 


pA Microampere 

um Micrometre 

us Microsecond 

a Alphabetic (see section 4.3, Data Element Format Conventions) 
AAC Application Authentication Cryptogram 
AC Application Cryptogram 

ACK Acknowledgment 

ADF Application Definition File 

AEF Application Elementary File 

AFL Application File Locator 

AID Application Identifier 

AIP Application Interchange Profile 

an Alphanumeric (see section 4.3) 

ans Alphanumeric Special (see section 4.3) 
APDU Application Protocol Data Unit 

API Application Program Interface 

ARC Authorisation Response Code 

ARPC Authorisation Response Cryptogram 
ARQC Authorisation Request Cryptogram 
ASI Application Selection Indicator 

ASN Abstract Syntax Notation 
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ATC Application Transaction Counter 

ATM Automated Teller Machine 

ATR Answer to Reset 

AUC Application Usage Control 

b Binary (see section 4.3) 

BCD Binary Coded Decimal 

BER Basic Encoding Rules (defined in ISO/IEC 8825-1) 
BIC Bank Identifier Code 

BGT Block Guardtime 

BWI Block Waiting Time Integer 

BWT Block Waiting Time 

C Celsius or Centigrade 

CAD Card Accepting Device 

C-APDU Command APDU 

CBC Cipher Block Chaining 

CCD Common Core Definitions 

CCI Common Core Identifier 

CDA Combined DDA/Application Cryptogram Generation 
CDOL Card Risk Management Data Object List 
CID Cryptogram Information Data 

Cin Input Capacitance 

CLA Class Byte of the Command Message 
CLK Clock 

cn Compressed Numeric (see section 4.3) 
CPU Central Processing Unit 

CRL Certificate Revocation List 

CSU Card Status Update 

C-TPDU Command TPDU 
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CV 
CVM 
CVR 

CV Rule 
CWI 


Hex 
HHMMSS 


Cryptogram Version 

Cardholder Verification Method 
Card Verification Results 
Cardholder Verification Rule 
Character Waiting Time Integer 
Character Waiting Time 

Bit Rate Adjustment Factor 
Destination Node Address 
Direct Current 

Dynamic Data Authentication 
Directory Definition File 
Dynamic Data Authentication Data Object List 
Data Encryption Standard 
Dedicated File 

Directory 

Data Object List 

Electronic Code Book 

Error Detection Code 
Elementary File 

European Norm 

Elementary Time Unit 
Frequency 

Format Code 

File Control Information 
Ground 

Grandparent key for session key generation 
Hexadecimal 


Hours, Minutes, Seconds 
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1/O Input/Output 

IAC Issuer Action Code (Denial, Default, Online) 

IAD Issuer Application Data 

IBAN International Bank Account Number 

I-block Information Block 

IC Integrated Circuit 

ICC Integrated Circuit(s) Card 

lec Current drawn from VCC 

IEC International Electrotechnical Commission 

IFD Interface Device 

IFS Information Field Size 

IFSC Information Field Size for the ICC 

IFSD Information Field Size for the Terminal 

IFSI Information Field Size Integer 

IIN Issuer Identification Number 

IK Intermediate Key for session key generation 

INF Information Field 

INS Instruction Byte of Command Message 

lox High Level Output Current 

Io, Low Level Output Current 

ISO International Organization for Standardization 

IV Initial Vector for session key generation 

Ky Master Key 

Kg Session Key 

L Length 

Ls. Least Significant 

Le Exact Length of Data Sent by the TAL in a Case 8 or 4 
Command 
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LCOL 
Lpp 


Le 


Lower Consecutive Offline Limit 


Length of the ICC Dynamic Data 


Maximum Length of Data Expected by the TAL in Response to 
a Case 2 or 4 Command 


Length 


Exact Length of Data Available or Remaining in the ICC (as 
Determined by the ICC) to be Returned in Response to the 
Case 2 or 4 Command Received by the ICC 


Length of Response Data Field 
Longitudinal Redundancy Check 
Mandatory 

Milliohm 

Most Significant 

Meters per Second 

Milliampere 

Message Authentication Code 
Maximum 

Master File 


Megahertz 


Minimum 

ICC Master Key for session key generation 
Millimetre 

Month, Day 

Month, Year 

Newton 

Numeric (see section 4.3) 

Node Address 


Negative Acknowledgment 


Nanoampere—second 


November 2011 


Page 25 


4 Abbreviations, Notations, Conventions, and Terminology EMV 4.3 Book 4 


4.1 Abbreviations 


Cardholder, Attendant, and Acquirer 
Interface Requirements 


Length of the Certification Authority Public Key Modulus 


Norme Francaise 


Length of the Issuer Public Key Modulus 
Length of the ICC Public Key Modulus 


National Institute for Standards and Technology 
Length of the ICC PIN Encipherment Public Key Modulus 


Nanosecond 

Optional 

Operating System 

Parent key for session key generation 
Parameter 1 

Parameter 2 

Parameter 3 

Primary Account Number 

Personal Computer 

Certification Authority Public Key 
Protocol Control Byte 

Processing Options Data Object List 
Picofarad 

Issuer Public Key 


ICC Public Key 


Personal Identification Number 

Proprietary Application Identifier Extension 
Point of Service 

Position 

Payment System Environment 


Protocol Type Selection 
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R-APDU 
R-block 
RFU 
RID 
RSA 
RST 
SAD 
S-block 


Response APDU 

Receive Ready Block 

Reserved for Future Use 

Registered Application Provider Identifier 

Rivest, Shamir, Adleman Algorithm 

Reset 

Source Node Address 

Supervisory Block 

Certification Authority Private Key 

Static Data Authentication 

Short File Identifier 

Secure Hash Algorithm 1 

Issuer Private Key 

ICC Private Key 

Session Key for session key generation 

Status Byte One 

Status Byte Two 

Terminal Action Code(s) (Default, Denial, Online) 
Terminal Application Layer 

Transaction Certificate 

Check Character 

Transaction Certificate Data Object List 

Fall Time Between 90% and 10% of Signal Amplitude 
Tag Length Value 

Transport Protocol Data Unit 

Rise Time Between 10% and 90% of Signal Amplitude 


Initial Character 
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TSI Transaction Status Information 
TTL Terminal Transport Layer 

TVR Terminal Verification Results 
UCOL Upper Consecutive Offline Limit 
UL Underwriters Laboratories Incorporated 
V Volt 

var. Variable (see section 4.3) 

Voc Voltage Measured on VCC Contact 
VCC Supply Voltage 

Vin High Level Input Voltage 

Vin Low Level Input Voltage 

Vou High Level Output Voltage 

VoL Low Level Output Voltage 

VPP Programming Voltage 

Vpp Voltage Measured on VPP contact 
WI Waiting Time Integer 

WTX Waiting Time Extension 

WWT Work Waiting Time 

YYMM Year, Month 

YYMMDD Year, Month, Day 
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4.2 Notations 


0’ to ‘9’ and 'A'to'F' 16 hexadecimal characters 


XX Any value 
A:=B A is assigned the value of B 
A=B Value of A is equal to the value of B 
A=Bmodn Integers A and B are congruent modulo the integer n, 
that is, there exists an integer d such that 
(A—B)=dn 
A mod n The reduction of the integer A modulo the integer n, that 


is, the unique integer r, 0 <r <n, for which there exists 
an integer d such that 


A=dntr 
A/n The integer division of A by n, that is, the unique 
integer d for which there exists an integer r, 0<r <n, 
such that 
A=dntr 
Y := ALG(K)[X] Encipherment of a data block X with a block cipher as 


specified in Annex A1 of Book 2, using a secret key K 


X = ALG“(K)[Y] Decipherment of a data block Y with a block cipher as 
specified in Annex A1 of Book 2, using a secret key K 


Y := Sign (S,)[X] The signing of a data block X with an asymmetric 
reversible algorithm as specified in Annex A2 of Book 2, 
using the private key Sx 


X = Recover(P,)[Y] The recovery of the data block X with an asymmetric 
reversible algorithm as specified in Annex A2 of Book 2, 
using the public key Px 


C :=(A || B) The concatenation of an n-bit number A and an m-bit 
number B, which is defined as C= 2™ A+ B. 
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Leftmost Applies to a sequence of bits, bytes, or digits and used 
interchangeably with the term “most significant”. If 
C=(A || B) as above, then A is the leftmost n bits of C. 


Rightmost Applies to a sequence of bits, bytes, or digits and used 
interchangeably with the term “least significant”. If 
C =(A | | B) as above, then B is the rightmost m bits 
of C. 


H := Hash[MSG] Hashing of a message MSG of arbitrary length using a 
160-bit hash function 


X@Y The symbol '' denotes bit-wise exclusive-OR and is 
defined as follows: 


X@®Y The bit-wise exclusive-OR of the data blocks 
X and Y. If one data block is shorter than the 
other, then it is first padded to the left with 
sufficient binary zeros to make it the same 
length as the other. 
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4.3 Data Element Format Conventions 


The EMV specifications use the following data element formats: 


a 


an 


ans 


cn 


Alphabetic data elements contain a single character per byte. The 
permitted characters are alphabetic only (a to z and A to Z, upper and 
lower case). 


Alphanumeric data elements contain a single character per byte. The 
permitted characters are alphabetic (a to z and A to Z, upper and lower 
case) and numeric (0 to 9). 


Alphanumeric Special data elements contain a single character per byte. 
The permitted characters and their coding are shown in the Common 
Character Set table in Annex B. 


There is one exception: The permitted characters for Application 
Preferred Name are the non-control characters defined in the 

ISO/IEC 8859 part designated in the Issuer Code Table Index associated 
with the Application Preferred Name. 


These data elements consist of either unsigned binary numbers or bit 
combinations that are defined elsewhere in the specification. 


Binary example: The Application Transaction Counter (ATC) is defined 
as “b” with a length of two bytes. An ATC value of 19 is stored as Hex 
'00 13'. 


Bit combination example: Processing Options Data Object List (PDOL) 
is defined as “b” with the format shown in Book 8, section 5.4. 


Compressed numeric data elements consist of two numeric digits 
(having values in the range Hex 'O'—'9') per byte. These data elements 
are left justified and padded with trailing hexadecimal 'F's. 


Example: The Application Primary Account Number (PAN) is defined as 
“cn” with a length of up to ten bytes. A value of 1234567890123 may be 
stored in the Application PAN as Hex '12 34 56 78 90 12 3F FF" witha 
length of 8. 


Numeric data elements consist of two numeric digits (having values in 
the range Hex '0'—'9') per byte. These digits are right justified and 
padded with leading hexadecimal zeroes. Other specifications 
sometimes refer to this data format as Binary Coded Decimal (“BCD”) or 
unsigned packed. 


Example: Amount, Authorised (Numeric) is defined as “n 12” witha 
length of six bytes. A value of 12345 is stored in Amount, Authorised 
(Numeric) as Hex '00 00 00 01 23 45". 
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var. Variable data elements are variable length and may contain any bit 
combination. Additional information on the formats of specific variable 
data elements is available elsewhere. 
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4.4 Terminology 


proprietary Not defined in this specification and/or outside the scope 
of this specification 


shall Denotes a mandatory requirement 


should Denotes a recommendation 
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Part Il 


General Requirements 
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5 Terminal Types and Capabilities 


5.1 Terminal Types 


As described in section 1, this specification addresses a broad spectrum of 
terminals. For the purpose of this specification, terminals are categorised by the 
following: 


e Environment: Attended or unattended 
e Communication: Online or offline 
e Operational control: Financial institution, merchant, or cardholder 


Table 1 defines the terms used to describe terminal types. 


Term Definition 


Attended An attendant (an agent of the merchant or of the acquirer) is 
present at the point of transaction and participates in the 
transaction by entering transaction-related data. The 
transaction occurs ‘face to face’. 


Unattended The cardholder conducts the transaction at the point of 
transaction without the participation of an attendant (agent 
of the merchant or of the acquirer). The transaction does not 
occur ‘face to face’. 


Online only The transaction can normally only be approved in real time 
by transmission of an authorisation request message. 
Offline with Depending upon transaction characteristics, the transaction 
online can be completed offline by the terminal or online in real 
capability time. It is equivalent to ‘online with offline capability’. 
Offline only The transaction can only be completed offline by the 
terminal. 
Operational Identifies the entity responsible for the operation of the 
control terminal. This does not necessarily equate to the actual 


owner of the terminal. 


Table 1: Terms Describing Terminal Types 


Within this specification, online reflects online communication to acquirer (or its 
agent). The acquirer is assumed to be capable of communicating to the issuer (or 
its agent). 
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The type of terminal shall be indicated in Terminal Type. The coding of Terminal 
Type using the three categories is shown in Annex A. 


5.2 Terminal Capabilities 


For the purpose of this specification, terminal capabilities are described in 
Terminal Capabilities and Additional Terminal Capabilities. 


The following categories shall be indicated in Terminal Capabilities: 


e Card data input capability - Indicates all the methods supported by the 
terminal for entering the information from the card into the terminal. 


e Cardholder Verification Method (CVM) capability - Indicates all the 
methods supported by the terminal for verifying the identity of the cardholder 
at the terminal. 


e Security capability - Indicates all the methods supported by the terminal for 
authenticating the card at the terminal and whether or not the terminal has 
the ability to capture a card. 


The following categories shall be indicated in Additional Terminal Capabilities: 


e Transaction type capability - Indicates all the types of transactions 
supported by the terminal. 


e Terminal data input capability - Indicates all the methods supported by 
the terminal for entering transaction-related data into the terminal. 


e Terminal data output capability - Indicates the ability of the terminal to 
print or display messages and the character set code table(s) referencing the 
part(s) of ISO/IEC 8859 supported by the terminal. 


The coding of Terminal Capabilities and Additional Terminal Capabilities using 
these categories is shown in Annex A. 
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5.3 Terminal Configurations 


Terminal capabilities and device components vary depending on the intended 
usage and physical environment. A limited set of configuration examples follow. 


Figure 1 illustrates an example of an attended terminal where the integrated 
circuit (IC) interface device (IFD) and PIN pad are integrated but separate from 
the POS device (such as for an electronic fund transfer terminal or an electronic 
cash register). 


Terminal 


; C = ‘Cancel’ 
Mag. stripe E = ‘Enter’ 
card 


Figure 1: Example of an Attended Terminal 
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Figure 2 illustrates an example of merchant host concentrating devices, which 
may be of various types and capabilities. 


Merchant Host 


POS Device 


Figure 2: Example of a Merchant Host 


Within this specification a merchant host to which is connected a cluster of POS 
devices shall be considered, in its totality, as a ‘terminal’ regardless of the 
distribution of functions between the host and POS devices. (See section 10 for 
terminal data management requirements.) 
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Figure 3 illustrates an example of a cardholder-controlled terminal that is 
connected via a public network to a merchant or acquirer host. 


Public Network 


Cardholder 
Terminal 
C = ‘Cancel’ 


E = ‘Enter Acquirer Host 


Figure 3: Example of a Cardholder-Controlled Terminal 
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6 Functional Requirements 


This Book does not replicate the other Books of the Integrated Circuit Card 
Specifications for Payment Systems but describes the implementation issues and 
the impact of those Books on the terminal. 


This section uses standard messages described in section 11.2 to illustrate the 
appropriate message displays for the transaction events described below. 


The usage of Authorisation Response Code, CVM Results, and Issuer Script 
Results is specified in this section. See Annex A for additional information on 
coding. 


6.1 Application Independent ICC to Terminal Interface 
Requirements 


The terminal shall comply with all Parts of Book 1. It shall support all data 
elements and commands subject to the conditions described in section 6.3. 


6.2 Security and Key Management 


The terminal shall comply with all Parts of Book 2. It shall support all data 
elements and commands subject to the conditions described in section 6.3. 


6.3 Application Specification 


The terminal shall comply with all Parts of Book 3. It shall support all functions 
subject to the conditions described in this section. 


Sections 6.3.1 to 6.3.9 expand upon the terminal functions described in Book 38. 
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6.3.1 Initiate Application Processing 


When the Processing Options Data Object List (PDOL) includes an amount field 
(either Amount, Authorised or Amount, Other), an attended terminal (Terminal 
Type = 'x1', 'x2' or 'x3') shall provide the amount at this point in transaction 
processing. If the amount is not yet available, the terminal shall obtain the 
amount and should display the ‘ENTER AMOUNT?’ message. For any other 
terminal type, if the terminal is unable to provide the amount at this point in 
transaction processing, the amount field in the data element list shall be filled 
with hexadecimal zeroes. 


As described in Book 3, if the card returns SW1 SW2 ='6985' in response to the 
GET PROCESSING OPTIONS command, indicating that the transaction cannot 
be performed with this application, then the terminal should display the ‘NOT 
ACCEPTED’ message and shall return to application selection. The terminal 
shall not allow that application to be selected again for this card session as 
defined in Book 1. 


6.3.2 Offline Data Authentication 


An online-only terminal supporting no form of offline data authentication as 
indicated in Terminal Capabilities shall set to 1 the ‘Offline data authentication 
was not performed’ bit in the Terminal Verification Results (TVR). (For details, 
see Annex C of Book 3.) 


All other terminals shall support both offline static data authentication (SDA) 
and offline dynamic data authentication (DDA and optionally CDA) as described 
in Books 2 and 3. 


When the selected form of offline data authentication is CDA and CDA fails prior 
to the final Terminal Action Analysis (for example, Issuer Public Key recovery 
fails prior to Terminal Action Analysis) preceding the issuance of a first 
GENERATE AC command, or second GENERATE AC command in the case 
‘unable to go online’, the terminal shall set the TVR bit for ‘CDA failed’ to 1 and 
request the cryptogram type determined by Terminal Action Analysis. In this 
case, the GENERATE AC command shall not request a CDA signature and no 
further CDA processing is performed. 


When the selected form of offline data authentication is CDA and a CDA failure 
is detected after the final Terminal Action Analysis preceding the issuance of a 
first or second GENERATE AC command, the terminal shall set the ‘CDA failed’ 
bit in the TVR to 1 and the following rules apply: 


If CDA fails in conjunction with the first GENERATE AC: 


e Ifthe Cryptogram Information Data (CID) bit indicates that the card has 
returned a TC, the terminal shall decline the transaction and not perform a 
second GENERATE AC command. 
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e Ifthe CID bit indicates that the card has returned an ARQC, the terminal 
shall complete the transaction processing by performing an immediate 
second GENERATE AC command requesting an AAC. 


If CDA fails in conjunction with the second GENERATE AC, the terminal 
shall decline the transaction 


If as part of dynamic signature verification the CID was retrieved from the ICC 
Dynamic Data (as recovered from the Signed Dynamic Application Data), then it 
is this value that shall be used to determine the cryptogram type. Otherwise the 
cleartext CID in the GENERATE AC response shall be used. 


Terminals supporting offline cryptography should support Certificate Revocation 
Lists (CRLs). If CRLs are supported, the support shall be in accordance with 
section 5.1.2 of Book 2. 


6.3.3 Processing Restrictions 


If the card and terminal Application Version Numbers are different, the terminal 
shall attempt to continue processing the transaction. If it is unable to continue, 
the terminal shall abort the transaction and should display the ‘NOT 
ACCEPTED’ message. 


When processing the Application Usage Control, the terminal must know 
whether or not it is an ATM. See Annex A1 for information on identifying an 
ATM. 


A terminal supporting cashback should not offer cashback facility to the 
cardholder if the Application Usage Control does not allow this option. 


6.3.4 Cardholder Verification Processing 


Recognition of a CVM means the CVM Code is understood by the terminal but 
not necessarily supported by the terminal. The terminal shall recognise the 
EMV-defined CVM codes in Annex C3 of Book 3 including the CVM codes for 'No 
CVM required' and 'Fail CVM processing. The terminal may also recognize 
proprietary CVM Codes not defined in Annex C3. 


Support for a CVM means the terminal has the hardware and software necessary 
to perform the CVM. Support for EMV-defined CVM codes is indicated in the 
following manner: 


e For EMV-defined CVM codes, support is indicated in Terminal Capabilities. 
e For CVM codes not defined in EMV, support may be known implicitly. 

e For Combination CVMs, both CVM codes must be supported. 

e Fail CVM shall always be considered supported. 

A CVM can be performed only if it is both recognised and supported. 
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6.3.4.1 Offline CVM 


When the applicable CVM is an offline PIN, the terminal should issue a 
GET DATA command to the card to retrieve the PIN Try Counter prior to issuing 
either the VERIFY command or GET CHALLENGE command. 


If the PIN Try Counter is not retrievable or the GET DATA command is not 
supported by the ICC, or if the value of the PIN Try Counter is not zero, 
indicating remaining PIN tries, the terminal shall prompt for PIN entry such as 
by displaying the message ‘ENTER PIN’. 

If the value of the PIN Try Counter is zero, indicating no remaining PIN tries, 
the terminal should not allow offline PIN entry. The terminal: 


e shall set the ‘PIN Try Limit exceeded’ bit in the TVR to 1 (for details on TVR, 
see Annex C of Book 3), 
e shall not display any specific message regarding PINs, and 


e shall continue cardholder verification processing in accordance with the card’s 
CVM List. 


If offline PIN verification by the ICC is successful, the terminal shall set byte 3 of 
the CVM Results to ‘successful’. Otherwise, the terminal shall continue 
cardholder verification processing in accordance with the card’s CVM List. (CVM 
Results is described in section 6.3.4.5 and coded according to Annex A4.) 


6.3.4.2 Online CVM 


When the applicable CVM is an online PIN, the IFD shall not issue a VERIFY 
command. Instead, the PIN pad shall encipher the PIN upon entry for 
transmission in the authorisation or financial transaction request. 


The terminal shall allow a PIN to be entered for online verification even if the 
card’s PIN Try Limit is exceeded. 


The terminal shall set byte 3 of the CVM Results to ‘unknown’. 
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6.3.4.3 PIN Entry Bypass 


If a PIN is required for entry as indicated in the card’s CVM List, an attended 
terminal with an operational PIN pad may have the capability to bypass PIN 
entry before or after several unsuccessful PIN tries.! If this occurs, the terminal: 


e shall set the ‘PIN entry required, PIN pad present, but PIN was not entered’ 
bit in the TVR to 1, 


e shall not set the ‘PIN Try Limit exceeded’ bit in the TVR to 1, 
e shall consider this CVM unsuccessful, and 


e shall continue cardholder verification processing in accordance with the card’s 
CVM List. 


When PIN entry has been bypassed for one PIN-related CVM, it may be 
considered bypassed for any subsequent PIN-related CVM during the current 
transaction. 


6.3.4.4 Signature (Paper) 


When the applicable CVM is signature, the terminal shall set byte 3 of the CVM 
Results to ‘unknown’. At the end of the transaction, the terminal shall print a 
receipt with a line for cardholder signature. (See Annex A2 for requirements for 
the terminal to support signature as a CVM.) 


1 This prevents a genuine cardholder who does not remember the PIN from having to 
keep entering incorrect PINs until the PIN is blocked in order to continue with the 
transaction. 
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6.3.4.5 CVM Results 


When the applicable CVM is ‘No CVM required’, if the terminal supports 

‘No CVM required’ it shall set byte 3 of the CVM Results to ‘successful’. When the 
applicable CVM is ‘Fail CVM processing’, the terminal shall set byte 3 of the 
CVM Results to ‘failed’. 


The terminal shall set bytes 1 and 2 of the CVM Results with the Method Code 
and Condition Code of the last CVM performed. After a successful CVM, CVM 
Results reflect the successful CVM. After an unsuccessful CVM with byte 1 bit 7 
of the CV Rule set to 0 (fail cardholder verification), CVM Results reflect the 
unsuccessful CVM. After an unsuccessful CVM with byte 1 bit 7 set to 1 (apply 
succeeding CVM), CVM Results reflect this unsuccessful CVM only when no 
subsequent CVMs are performed; that is, when for each subsequent CV Rule 
either the CVM condition is not satisfied or the CVM condition is satisfied but 
the CVM method is not supported or is not recognised. If a subsequent CVM is 
performed, CVM Results reflect the outcome of the subsequent CVM. 


If the last CVM performed was not considered successful (byte 3 of the CVM 
Results is not set to ‘successful’ or ‘unknown’, the terminal shall set byte 3 of the 
CVM Results to ‘failed’. 


If no CVM was performed (no CVM List present or no CVM conditions satisfied), 
the terminal shall set byte 1 of the CVM Results to ‘No CVM performed’. 


Table 2 on the following page shows the setting of CVM Results, Byte 3 of 
Terminal Verification Results (TVR) related to CVM processing, and the 
Transaction Status Information (TSI) bit for CVM processing for some conditions 
that may occur during CVM List processing. Please note that for the first five 
entries in the table, the second byte of the CVM Results has no actual meaning so 
it is recommended it be set to '00'. 
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Corresponding CVM Results TSI 
Conditions mies Byte 1 
Byte 1 Byte 2 Byte 3 Byte 3 bit 7 
(CVM Performed) (CVM Condition) (CVM Result) 
ae '3F' 
ee Ae card does not support cardholder verification (AIP (Book4 Section 6.2:4.5 ‘00! (no meaning) 00! 0 
and Annex A4) 
Vac : '3F' 0 
ae CVM List is not present or the CVM List has no CVM (Bock 4 Section 63.4.6 ‘o0r oaneaning) 00! (Book 3 
and Annex A4) Section 10.5) 
'3F' 
When no CVM Conditions in CVM List are satisfied (Book 4 Section 6.3.4.5 '00' (no meaning) ‘O1' bit 8 = 1 
and Annex A4) 
: 19F" 
When the terminal does not support any of the CVM Codes ; ani : Ber Pee 
in CVM List where the CVM Condition was satisfied (Book 4 Section 6.3.4.5 QO" (Ho meaning) e pu oe 
and Annex A4) 
When the terminal does not recognise any of the CVM '3F' bit 8=1 
Codes in CVM List (or the code is RFU) where the CVM (Book 4 Section 6.3.4.5 '00' (no meaning) ‘Ol bi ae 
ie ie it 7 = 
Condition was satisfied and Annex A4) 
‘O1' 
Pere dad '00' or '40' The CVM Condition Code for (Book 4 aE ere 
Shen the ase) pobfonmod CV Mas EAC NM. procese:ne (Not recommended for cards.) the CVM Code in Byte 1 Section 6.3.4.5 BER 
and Annex A4) 
; The CVM Code for the last The CVM Condition Code for Lae sel aigs eka 
When the last performed CVM fails perfgrined CVM the CVM Code in Byte 1 01 bit 8=1 
00" 
Siew ; ‘1E' or '5E' The CVM Condition Code for (Book 4 
Ween the: CNM pebiormedis: Sienatuie (CVM Code for 'Signature') the CVM Code in Byte 1 Section 6.3.4.4 
and Annex A4) 


Table 2: Setting of CVM Results, TVR bits and TSI bits following CVM Processing 


2 Errors with PIN related CVMs may also result in the setting of other PIN-related TVR bits. 
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Corresponding CVM Results TVR TSI 
Conditions Byte 1 
Byte 1 Byte 2 Byte 3 Byte 3 bit 7 
(CVM Performed) (CVM Condition) (CVM Result) 
'00' 
ee eee: ; '02' or '42' The CVM Condition Code for (Book 4 eee 

Mben the CMM ipenormed 1 Online RLY (CVM Code for 'Online PIN’) the CVM Code in Byte 1 Section 6.3.4.2 Le ae : 

and Annex A4) 

'02' 
Ley fs: '1F' or '5F" The CVM Condition Code for (Book 4 

Semen the CM performed as No Cu Mrpame’ (CVM code for 'No CVM Required’) the CVM Code in Byte 1 Section 6.3.4.5 ‘ 

and Annex A4) 
When a CVM is performed and fails with the failure : 
action being 'Go to Next' and then the end of the CVM write ae oa poate The CVM Condition Code for ‘ol! bit 8=1 1 
List is reached without another CVM Condition being m UG ‘ the CVM Code in Byte 1 = 
satisfied was satisfied (but that failed). 
When the CVM performed is a combination CVM Code, CVM Code for the combination The CVM Condition Code for ‘Ol! bit 8= 12 1 
and at least one fails and the failure action is Fail CVM CVM the CVM Code in Byte 1 
When the CVM performed is a combination CVM Code, CVM Code for the combination The CVM Condition Code for 00! 1 
and one passes and the result of the other is 'unknown' CVM the CVM Code in Byte 1 


Table 2: Setting of CVM Results, TVR bits and TSI bits following CVM Processing, continued 
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6.3.5 Terminal Risk Management 


In addition to the terminal risk management functions described in Book 3 and 
regardless of the coding of the card’s Application Interchange Profile bit setting 
for ‘Terminal Risk Management is to be performed’, a terminal may support an 
exception file per application. 


When the terminal has an exception file listing cards and associated applications, 
the terminal shall check the presence of the card (identified by data such as the 
Application Primary Account Number (PAN) and the Application PAN Sequence 
Number taken from the currently selected application) in the exception file. 


If a match is found in the exception file, the terminal shall set the ‘Card appears 
in exception file’ bit in the TVR to 1. 


6.3.6 Terminal Action Analysis 


As described in Book 3, during terminal action analysis the terminal determines 
whether the transaction should be approved offline, declined offline, or 
transmitted online by comparing the TVR with both Terminal Action Code - 
Denial and Issuer Action Code - Denial, both Terminal Action Code - Online and 
Issuer Action Code - Online, and both Terminal Action Code - Default and Issuer 
Action Code - Default. 


e Ifthe terminal decides to accept the transaction offline, it shall set the 
Authorisation Response Code to ‘Offline approved’.? 


e Ifthe terminal decides to decline the transaction offline, it shall set the 
Authorisation Response Code to ‘Offline declined’. 


e Ifthe terminal decides to transmit the transaction online, it shall not set a 
value for the Authorisation Response Code nor change the value for the 
Authorisation Response Code returned in the response message. 


3 This does not mean that the transaction will be approved. The card makes the final 
decision and returns it to the terminal in its response to the first GENERATE AC 
command. 
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6.3.7 


Card Action Analysis 


In response to the GENERATE APPLICATION CRYPTOGRAM (AC) command, 
the card returns CID. Based on the CID, the terminal shall process the 


transaction as follows: 


If the card indicates: 


then the terminal: 


approval e shall complete the transaction 
e should display the ‘APPROVED’ message 
decline e shall decline the transaction 


e should display the ‘DECLINED’ message 


process online 


advice, and if advices 
are supported by the 
terminal and terminal 
acquirer interface 
protocol 


shall transmit an authorisation or financial transaction 
request message, if capable 


(See section 12.2.1 for exception handling when the 
terminal is unable to go online.) 


« shall not, if the transaction is captured, create 
an advice message. 


« shall, if the transaction is not captured (such as 
a decline), either transmit an online advice if 
online data capture is performed by the 
acquirer, or create an offline advice for batch 
data capture. 


(See section 12.2.5 for exception handling when the 
terminal is unable to create an advice) 


advice, and if advices 
are not supported by 
the terminal and 
terminal acquirer 
interface protocol 


does not create an advice. 


‘Service not allowed’ 


e shall terminate the transaction 
e should display the ‘NOT ACCEPTED’ message 


Table 3: Card Action Analysis 
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6.3.8 Online Processing 


Depending on the Authorisation Response Code returned in the response 
message, the terminal shall determine whether to accept or decline the 
transaction. It shall issue the second GENERATE AC command to the ICC 
indicating its decision. 


The result of card risk management performed by the ICC is made known to the 
terminal through the return of the CID indicating either a transaction certificate 
(TC) for an approval or an application authentication cryptogram (AAC) for a 
decline. 


When online data capture is performed by the acquirer, the terminal shall send a 
reversal message if the final decision of the card is to decline a transaction for 
which the Authorisation Response Code is ‘Online approved’. 


6.3.9 Issuer-to-Card Script Processing 


The terminal shall be able to support one or more Issuer Scripts in each 
authorisation or financial transaction response it receives, where the total length 
of all Issuer Scripts in the response shall be less than or equal to 128 bytes. 


Note: In this case and when only one Issuer Script (tag ‘71’ or “72’) is sent, and no Issuer 
Script Identifier is used, the maximum length of the Issuer Script Command (tag ‘86’) is 

limited to 124 bytes. This implies that the maximum available useful command data (Lc) 
is limited to 119 bytes for a Case 3 command. 


The terminal shall be able to recognise the tag for the Issuer Script transmitted 
in the response message. If the tag is '71', the terminal shall process the script 
before issuing the second GENERATE AC command. If the tag is '72', the 
terminal shall process the script after issuing the second GENERATE AC 
command. 


For each Issuer Script processed, the terminal shall report the Script Identifier 
(when present) with its result in the Issuer Script Results. If an error code was 
returned by the card for one of the single Script Commands, the terminal shall 
set the most significant nibble of byte 1 of the Issuer Script Results to ‘Script 
processing failed’ and the least significant nibble with the sequence number of 
the Script Command in the order it appears in the Issuer Script. If no error code 
was returned by the card, the terminal shall set the most significant nibble of 
byte 1 of the Issuer Script Results to ‘Script processing successful’ and the least 
significant nibble to '0'. See Annex A5 for details. 


The terminal shall transmit the Issuer Script Results in the batch data capture 
message (financial record or offline advice), the financial transaction 
confirmation message, or the reversal message. If no message is created for the 
transaction (such as a decline), the terminal shall create an advice to transmit 
the Issuer Script Results, if the terminal supports advices. 
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6.4 Conditions for Support of Functions 


A terminal supporting offline PIN verification shall support the VERIFY 
command. A terminal supporting offline PIN encipherment shall also support the 
GET CHALLENGE command. A terminal not supporting offline PIN verification 
need not support the VERIFY command. 


An offline-only terminal and an offline terminal with online capability shall 
support both SDA and DDA and may optionally support CDA. 


An online-only terminal need not support SDA or DDA or CDA. Individual 
payment systems will define rules for this case. 


An offline-only terminal and an offline terminal with online capability shall 
support terminal risk management. An offline-only terminal and an online-only 
terminal need not support random transaction selection. 


An online-only terminal need not support all of the terminal risk management 
functions. In this case, the acquirer (or its agent) should process the transaction 
instead of the terminal according to Book 3. In other words, the acquirer should 
perform the remaining terminal risk management functions. Individual payment 
systems will define rules for this case. 


A financial institution- or merchant-controlled terminal (Terminal Type = '1x' or 
'2x') shall support the terminal risk management functions described in Book 3. 
A cardholder-controlled terminal (Terminal Type = '3x') need not support 
terminal risk management. 
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6.5 Other Functional Requirements 


6.5.1 Amount Entry and Management 


The amount of a transaction shall be indicated to the cardholder preferably by 
means of a terminal display or labels, such as posted prices on a vending 
machine, or alternatively by printing on a receipt. 


When the amounts are entered through the use of a keypad the terminal should 
allow the amount to be displayed during entry. The attendant or cardholder 
should be able to either correct the amounts entered prior to authorisation and 
proceed with the transaction or cancel the transaction if the amount was entered 
incorrectly. 


The cardholder should be able to validate the original or corrected amount when 
the transaction amount is known before authorisation. If PIN entry occurs 
immediately after the amounts are entered, PIN entry can act as the validation 
of the amount. If PIN entry does not occur immediately after the amounts are 
entered, the terminal should display the ‘(Amount) OK?’ message for the 
cardholder to validate the amount fields. 


If the authorisation takes place before the final transaction amount is known (for 
example, petrol at fuel dispenser, amount before tip at restaurant), the Amount, 
Authorised data object represents the estimated transaction amount and the 
Transaction Amount data object represents the final transaction amount as 
known at the end of the transaction. 


The cardholder may have the ability to separately enter or identify a cashback 
amount. When cashback is allowed, the cashback amount shall be transmitted in 
the Amount, Other data object. The amounts transmitted in Amount, Authorised 
and Transaction Amount shall include both the purchase amount and cashback 
amount (if present). 


When passed to the ICC as part of the command data, the Amount, Authorised 
and Amount, Other shall be expressed with implicit decimal point (for example, 
'123' represents £1.23 when the currency code is '826'). 


6.5.2 Voice Referrals 


A manual voice referral process may be initiated by the issuer. 


An attended terminal shall be capable of supporting voice referrals, (that is, it 
shall be capable of alerting the attendant when the issuer indicates a referral). 
An unattended terminal is not required to support voice referrals. If a referral 
cannot be performed, default procedures are in place for the individual payment 
systems to decide how the transaction shall be handled (for example, approve 
offline, or decline offline). 
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6.5.2.1 Referrals Initiated by Card 
This functionality was removed by bulletin SU42. 


6.5.2.2. Referrals Initiated by Issuer 


When the Authorisation Response Code in the authorisation response message 
indicates that a voice referral should be performed by the attendant, prior to 
issuing the second GENERATE AC command, an attended terminal shall either 
display the ‘CALL YOUR BANK’ message to the attendant, or shall alert the 
attendant in some other way that the Issuer has requested a voice referral. 
Appropriate application data, such as the Application PAN, should be displayed 
or printed to the attendant in order to perform the referral. Appropriate 
messages should be displayed requesting the attendant to enter data indicating 
that the transaction has been approved or declined as a result of the referral 
process. The attendant may manually override the referral process and may 
accept or decline the transaction without performing a referral. 


The terminal shall not modify the Authorisation Response Code. The terminal 
shall issue the second GENERATE AC command requesting either a TC for an 
approval or an AAC for a decline. If the Issuer Authentication Data is present in 
the authorisation response message, the terminal may issue the EXTERNAL 
AUTHENTICATE command either before or after the referral data is manually 
entered. 


6.5.3 Transaction Forced Online 


An attended terminal may allow an attendant to force a transaction online, such 
as in a situation where the attendant is suspicious of the cardholder. If this 
function is performed, it should occur at the beginning of the transaction. If this 
occurs, the terminal shall set the ‘Merchant forced transaction online’ bit in the 
TVR to 1. Payment systems rules will determine whether the attendant is 
allowed to perform such a function. 


6.5.4 Transaction Forced Acceptance 


An attended terminal may allow an attendant to force acceptance of the 
transaction, even if the card has returned an AAC indicating that the transaction 
is to be declined. If this occurs, the transaction shall be captured for clearing as a 
financial transaction either by sending an online financial advice or within the 
batch data capture. The terminal shall not modify the Authorisation Response 
Code and shall set an indicator that the attendant forced acceptance of the 
transaction in the online advice or batch data capture. Payment systems rules 
will determine whether the attendant is allowed to perform such a function. 
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6.5.5 Transaction Sequence Counter 


The terminal shall maintain a Transaction Sequence Counter that is 
incremented by one for each transaction performed by the terminal. The 
Transaction Sequence Counter may be common to both ICC and non-ICC 
transactions. 


The initial value of this counter is one. When the Transaction Sequence Counter 
reaches its maximum value, it shall be reset to one. A value of zero is not 
allowed. (See Book 3 for details on this data element.) 


The Transaction Sequence Counter may be used for transaction logging or 
auditing as well as for input to the application cryptogram calculation. 


6.5.6 Unpredictable Number 


The terminal shall be able to generate an Unpredictable Number, which may be 
used for input to the application cryptogram algorithm to ensure the 
unpredictability of data input to this calculation or for random transaction 
selection for terminal risk management. An unpredictable number shall be 
generated in accordance with an individual payment system’s specifications. 


The Unpredictable Number could be generated by a dedicated hardware random 
number generator or could, for example, be a function of previous Application 
Cryptograms, the terminal Transaction Sequence Counter and other variable 
data (e.g. date/time). In the second example the function could be a hash function 
or more preferably a keyed encipherment function. 


6.6 Card Reading 


If the terminal does not have a combined IC and magnetic stripe reader, when 
the magnetic stripe of the card is read and the service code begins with a '2' ora 
'6' indicating that an IC is present, the terminal shall prompt for the card to be 
inserted into the IC reader such as by displaying the ‘USE CHIP READER’ 
message. 


If the terminal has a combined IC and magnetic stripe reader, when the 
magnetic stripe of the card is read and the service code begins with a '2' or a '6' 
indicating that an IC is present, the terminal shall process the transaction using 
the IC. 
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6.6.1 IC Reader 


The IFD should have a pictogram near the card slot indicating how to insert the 
card into the IC reader. 


As soon as the card is inserted into the reader, the message ‘Please Wait’ should 
be displayed to reassure the cardholder or attendant that the transaction is being 
processed so that the card is not removed prematurely. 


When the card is inserted into the IFD, the card should be accessible to the 
cardholder at all times during the transaction. When the card is not accessible at 
all times or when the terminal has a ‘tight grip’ to hold the card, there should be 
a mechanism, for example, a button, to recall or release the card in case of 
terminal malfunction, even if there is a power failure. For an unattended 
terminal with card capture capability, where captured cards remain in the secure 
housing of the terminal (such as for an ATM), the card release function is not 
required. 


When the card is inserted into the IFD, the cardholder or attendant should not be 
able to accidentally dislodge the card from the reader. 


If the card is removed from the terminal prior to completion of the transaction, 
the terminal should abort the transaction and should ensure that neither the 
card nor the terminal is damaged. The message ‘Processing Error’ should be 
displayed. (For additional requirements on abnormal termination of transaction 
processing, see Book 3.) 


6.6.2 Exception Handling 


When an attended terminal attempts and fails to read the ICC but the magnetic 

stripe of the card is successfully read, the terminal shall set the POS Entry Mode 
Code in the transaction message(s) to ‘Magnetic stripe read, last transaction was 
an unsuccessful IC read’ if the service code on the magnetic stripe indicates that 

an IC is present.? 


Payment system rules determine whether fallback to magnetic stripe is allowed 
after the failure of an IC-read transaction. This behaviour is outside the scope of 
EMV specifications. 


5 This does not imply that the terminal shall support this ISO 8583:1987 data element. 
An issuer or an acquirer may define an equivalent data element. The specific code will be 
set by individual payment systems. 
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6.7 Date Management 


6.7.1 Data Authentication 


The terminal shall be capable of properly calculating dates associated with data 
authentication (certificate expiration dates) for dates before, including, and after 
the year 2000. 


6.7.2 Processing Restrictions 


The terminal shall be capable of properly calculating dates associated with 
processing restrictions (Application Expiration Date, Application Effective Date) 
for dates before, including, and after the year 2000. 


6.7.3. Date Management 


To ensure the accuracy of the data elements Transaction Date (local date) and 
Transaction Time (local time), the terminal shall ensure that it 1s able to 
accurately calculate, store, and display date-dependent fields representing the 
year 2000 and subsequent years without compromising the integrity of dates or 
their use, including calculations for leap years. This requirement applies to 
terminals supporting clocks as well as those that update the date and the time 
based upon on-line messages. 


The terminal should process a 2-digit year (YY) as follows: 
e YY in the range 00—49 inclusive is treated as having the value 20YY 
e YY in the range 50-99 inclusive is treated as having the value 19YY 


The same rules shall be used if the terminal converts 2-digit years in format YY 
to 4-digit years in format YYYY. 
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7 Physical Characteristics 


Physical characteristics vary depending on the intended usage of the terminal, 
the environment at the point of transaction (including its security), and the 
terminal configuration. 


7.1 Keypad 


A terminal should have a keypad for the entry of transaction-related data and its 
functional operation. The keypad shall support one or more types of keys , as 
listed in Table 4. 


Numeric ‘O' —'9! 

Alphabetic and special For example, 'A'—'Z', '*', '#' 

Command ‘Cancel’, 'Enter', 'Clear' 

Function Application-dependent keys, such as a selection key, 
'F1', 'F2', 'Backspace’, 'Escape' 


Table 4: Key Types 


A keypad may consist of a single key, such as a function key that could be a 
button on a vending machine to indicate selection of an application or to indicate 
that a receipt is to be printed. 


A touch screen is considered to be a keypad. (See Book 2 for security 
requirements.) 
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7.1.1 Command Keys 


Command keys are used to control the flow of data entry by the cardholder or 
attendant. Table 5 describes the command keys: 


Confirms an action 


Either cancels the whole transaction or, if no 'Clear' key is 


present, cancels the operation in progress 


Erases all the numeric or alphabetic characters previously 
entered 


Table 5: Command Keys 


If the colours green, red, or yellow are used, either for key lettering or the keys 
themselves, it is recommended that they be reserved for the command keys 


according to Table 6: 


Table 6: Command Key Colours 


When the command keys are horizontally arranged, the 'Cancel' and 'Enter' keys 
should be located on the bottom row of the keypad, and 'Cancel' should be the 
furthest key left and 'Enter' should be the furthest key right. When the command 
keys are vertically arranged, 'Cancel' should be the uppermost key and 'Enter' 
the lowest key. 
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7.1.2 PIN Pad 


The terminal should be designed and constructed to facilitate the addition of a 
PIN pad, if not already present, such as by having a serial port. 


If the terminal supports PIN entry, a separate keypad may be present for PIN 
entry or the same keypad may be used for both PIN entry and entry of other 
transaction-related data. The PIN pad shall comprise the numeric and 'Enter' 
and 'Cancel' command keys. If necessary, the command key for 'Clear' may also 
be present. 


It is recommended that the numeric layout of the PIN pad shall comply with 
ISO 9564 as shown in Figure 4, except for cardholder-controlled terminals such 
as personal computers (PCs), where the keyboard may contain a numeric keypad 
in a different format for PIN entry. An example of the placement of the 'Cancel' 
and 'Enter' keys on the bottom row is shown in Figure 4. 


Cancel Enter 


(~J-J-] 
BOGE 
Teel) 


Figure 4: PIN Pad Layout 


The key for '5' should have a tactile identifier (for example, a notch or raised dot) 
to indicate to those whose sight is impaired that this is the central key from 
which all others may be deduced. 
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7.2 Display 


A display is used to help the cardholder or attendant monitor transaction flow 
and data entry, validate transaction-related data, and select options. 


An attended terminal shall have a display for the attendant and may have an 
additional display for the cardholder, such as when a PIN pad is present. In order 
that different information may be displayed and different languages used for the 
attendant and cardholder, it is reeommended that an attended terminal has two 
separate displays. 


An unattended terminal should have a cardholder display. 


At a minimum, the message display shall be capable of displaying at least 32 
alphanumeric characters (two lines of 16 positions each). The two lines of 16 
characters should be simultaneously displayed. To facilitate the display of 
different languages used in different geographical areas, the terminal should 
support a graphic display. 


A terminal capable of supporting several applications should have a display that 
can provide cardholder application selection by allowing the 16-character 
Application Preferred Name(s) or Application Label(s) stored in the ICC to be 
displayed. 


7.3 Memory Protection 


Software as well as data initialised in the terminal or any part of the terminal, 
including cryptographic keys, shall not be erased or altered for the period of time 
the software and data are valid. 


When the terminal supports batch data capture, the captured transactions and 
advices stored in the terminal shall not be erased or altered until the next 
reconciliation with the acquiring system. 


7.4 Clock 


Offline-only terminals and offline terminals with online capability shall have a 
clock with the local date and time. 


The date is used for checking certificate expiration dates for data authentication 
and/or offline PIN encipherment as well as application expiration/effective dates 
for processing restrictions. The time may be used for assuring transaction 
identification uniqueness as well as for input to the application cryptogram 
algorithm. 
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7.5 Printer 


A terminal should have a printer for receipt printing. If present, the printer shall 
be able to print at least 20 alphanumeric characters per line (see section 11.4). 


Cardholder-controlled terminal (Terminal Type = '3x') need not include a printer. 


7.6 Magnetic Stripe Reader 


In addition to an IC reader, a terminal shall be equipped with a magnetic stripe 
reader, except when payment system rules indicate otherwise. These rules will 
cover situations when a magnetic stripe reader is not required or not allowed for 
a financial institution- or merchant-controlled terminal (Terminal Type = '1x' or 
'2x'). A cardholder-controlled terminal (Terminal Type = '3x') need not include a 
magnetic stripe reader. 


The magnetic stripe reader shall be able to read the full track 1 and/or track 2 
and process according to the payment system rules. 
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Part Ill 


Software Architecture 
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8 Terminal Software Architecture 


This section is intended to provide insight for terminal manufacturers into the 
future direction of the payment system applications and the consequent 
requirements for terminal functionality. While terminals without this 
functionality may operate satisfactorily in today’s environment, changes in that 
environment will enhance the longevity of and provide functional advantages to 
terminals incorporating the software design principles in this section. 


8.1 Environmental Changes 


In today’s environment, support of payment system functions is provided in the 
typical POS terminal by one or possibly two applications based on the limited 
data available from the magnetic stripe of a payment system card. Differences in 
cards presented are largely contained in host systems and are usually 
transparent to the terminal software. 


The ICC replaces this environment with cards that may have multiple diverse 
applications, with significantly larger amounts of data representing a large 
number of options that must be interpreted by the terminal. The typical terminal 
will support multiple applications, with varying degrees of similarity. 
Applications may be modified annually, presenting additional challenges to 
software migration in the terminal. New applications will almost certainly be 
added during the life of a terminal. There will be a need to add applications 
efficiently and without risk to existing applications. Modification or addition of 
applications should be done in such a way that unaffected applications need not 
be re-certified. Code should be reusable and sharable with adequate security 
controls to accomplish such migration with efficiency and integrity. 


Greater differentiation between the payment systems should be anticipated at 
the terminal, expressed by data contained within the ICC. This may (and 
probably will) be carried down to regional and even issuer levels, requiring the 
terminal to keep a library of routines available for selection by the card. The 
terminal may support only a subset of alternative routines, but terminals that 
support more will be at an advantage in the marketplace. 


At the level of this specification, the payment systems view two alternative 
software architectures as providing the capabilities required. These two 
alternatives are called the ‘Application Program Interface (APJ)’ and the 
‘Interpreter’ approaches. 
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8.2 Application Libraries 
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Figure 5: Terminal Software 


With either the API or the interpreter approach, the terminal should have the 
ability to maintain an application library of modules or routines that may be 
dynamically incorporated into the processing of a given transaction. Modules in 
the application library may be complete application programs, or they may be 
subroutines to be called upon at the direction of data within the terminal or the 
ICC. In the case of an interpreter capability, these modules will be code, written 
in a virtual machine instruction set implemented within the terminal, to be 
interpreted by the terminal control program. In the case of the API approach, 
modules will be object code written to the specific terminal architecture. 


In either case, modules within the application library may be dynamically 
invoked either by logic with the terminal application software or under the 
direction of referencing data kept within the ICC. The format and specification of 
external references are under control of the individual payment systems. 


A terminal may contain several libraries, some accessible to all applications and 
some restricted to particular applications or payment systems. 
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8.3 Application Program Interface 


This section describes a terminal software architecture through which 
application programs can make use of a set of essential and frequently used 
functions provided in terminals through a standard interface - the API. 


The API takes the form of a library of functions that can be used by all 
applications stored in the terminal. The functions in the library may be 
dynamically linked into the application programs that use them. 


The provision of these functions as a library in the terminal has a number of 
advantages: 


e Each application program in the terminal does not need to include the same 
code to implement standardised functionality. The implementation of only one 
copy of code in each terminal to perform this functionality is very efficient in 
terminal memory. 


e Application programs do not need to take account of particular terminal 
hardware configurations, as these will be transparent to the application 
program at the API. The implications of a particular terminal’s hardware 
implementation are embedded within the code of the library function that has 
been certified for that terminal. 


e Certification of new terminal application programs will take place against the 
standardised and approved API function library for a particular terminal and 
does not require the re-certification of existing terminal applications programs 
(as would be the case with a single terminal program). The verification of 
firewalls between application programs is considerably eased by this 
architecture. 


While a single library of functions is used to construct the API, the library 
contains functions in two broad classes: 


e Functions that implement the application selection functionality described in 
Book 1 


e Functions that implement essential and frequently used terminal hardware 
functionality (for example, display, get key entry, etc.) 


Functions in the library may use other functions within the library. For example, 
SDA may use a terminal hardware function to read data from an application on 
the card. 


Functions in the library may be written using either terminal dependent object 
code or a more general virtual machine instruction set. 
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8.4 Interpreter 


8.4.1 Concept 


This section describes the general architecture underlying an interpreter 
implementation and gives a brief overview of how it relates to the future 
environment for payment system applications. 


Use of ICC technology necessitates altering the firmware in all terminals that 
accept ICCs. To facilitate this transition, an interpreter may be implemented as a 
software system that is compact, efficient, and easy to maintain and enhance for 
future payment system needs. The name arises from the capability of a terminal 
to contain central processing unit (CPU)-independent application programs and 
plugs that can be interpreted during a transaction to determine the terminal’s 
behaviour. 


An interpreter implementation defines a single software kernel, common across 
multiple terminal types. This kernel creates a virtual machine that may be 
implemented on each CPU type and that provides drivers for the terminal’s 
input/output (I/O) and all low-level CPU-specific logical and arithmetic functions. 
High-level libraries, terminal programs and payment applications using standard 
kernel functions may be developed and certified once; thereafter, they will run on 
any conforming terminal implementing the same virtual machine without 
change. Therefore, a significant consequence of an interpreter is a simplified and 
uniform set of test and certification procedures for all terminal functions. 


To summarise, interpreters provide the following major benefits: 


e A kernel with generalised ICC support functions, to be installed in each 
terminal only once. The kernel lifetime is expected to match that of the 
terminal (7-10 years). 


e One version of the terminal software kernel across multiple processor and 
terminal types. Therefore, only one certification and validation is needed for 
software libraries, terminal programs, and payment applications on the set of 
terminal types supported using a common interpreter/virtual machine. 


e Terminal kernel certification independent of applications, so certification only 
needs to be performed once for each terminal type using a common 
interpreter/virtual machine. A terminal type is defined as a specific 
configuration of terminal CPU and I/O functions. 


e Support for CPU-independent plugs that can be interpreted during a 
transaction to enhance a terminal’s behaviour. CPU independence means that 
only one certification and validation is needed for this code. 
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8.4.2 Virtual Machine 


The application software in every terminal using the interpreter approach is 
written in terms of a common virtual machine. The virtual machine is a 
theoretical microprocessor with standard characteristics that define such things 
as addressing mode, registers, address space, etc. 


The virtual machine accesses memory in two areas: code space and data space. 
All code accesses are internal to the virtual machine only and are not available to 
programs; the memory fetch and store operators access data space only. 
Translated program code only exists in code space. No terminal software 
(libraries or other functions external to the kernel) can make any assumptions 
regarding the nature or content of code space or attempt to modify code space in 
any way. This restriction, plus the complete absence of a symbol table, adds 
significantly to program security. 


8.4.3 Kernel 


A kernel contains all functions whose implementation depends upon a particular 
platform (CPU and operating system). It includes a selected set of commands, 
plus a number of specialised functions, such as terminal I/O support and program 
loader/interpreter support. 


8.4.4 Application Code Portability 


Virtual machine emulation may be accomplished by one of three methods: 
interpreting virtual machine instructions, translating the virtual machine 
language into a directly executable ‘threaded code’ form, or translating it into 
actual code for the target CPU. The latter two methods offer improved 
performance at a modest cost in complexity. 


The kernel for each particular CPU type is written to make that processor 
emulate the virtual machine. The virtual machine concept makes a high degree 
of standardisation possible across widely varying CPU types and simplifies 
program portability, testing, and certification issues. 


Programs may be converted to an intermediate language, between the high-level 
source language used by the programmer and the low-level machine code 
required by the microprocessor, and subsequently transported to the target 
terminal to be processed by the terminal into an executable form. 
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8.5 Plugs and Sockets 


One function of ICCs is to improve transaction security by incorporating and 
managing enciphered data and participating actively in the transaction 
validation process. Under this concept, the payment systems define a number of 
procedures (referred to as ‘sockets’) that may be inserted by the application 
programmer (and hence under acquirer control and under payment system 
supervision) to act as placeholders for the addition of enhancing code during 
transaction processing. 


Sockets are intended to be placed at various points in existing terminal 
applications or even in the terminal program itself. They are used to refer to 
library functions and may even occur inside a library function if a payment 
system foresees the need to change the way a library function operates. 


Sockets are initialised to default behaviours. If no further action is taken by the 
terminal program, the default behaviour of these procedures will be to do nothing 
when they are executed. 


Plugs are executable code, written in the machine language or virtual machine 
instruction set supported by the terminal, that may be inserted at points defined 
by sockets to enhance the default terminal logic. Plugs may already exist in the 
terminal to be invoked under control of data in the ICC and logic in the terminal. 
Plugs may also come from an input device (such as the ICC or a host system 
connected to the terminal), but only if agreed by the payment system, issuer, 
acquirer, and merchant. Special care may be required for ICC plugs if they can 
modify a socket’s behaviour or be placed in the program flow prior to successful 
card authentication. 


At the conclusion of a transaction, the sockets are restored to their original 
application default behaviours. 


The proposed terminal architecture does not propose that ICCs contain entire 
applications but only plugs that enhance existing terminal applications. 
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Figure 6 illustrates the relationship between plugs and sockets. 


Input Device Terminal 


Socket 


Socket 


Figure 6: Socket/Plug Relationship 
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9 Software Management 


A means of software upgrade shall be supported wherever this is not in conflict 
with national legal restrictions. The software upgrade may be facilitated from a 
remote site over a network or locally. 


Software upgrade may be performed under terminal application control or under 
terminal owner or acquirer human control. 


When software upgrade is performed under terminal application control, prior to 
accepting new software, the terminal shall: 


e Verify the identity of the party loading the software, since only software 
issued by the terminal manufacturer, owner, or a third party approved by the 
owner or acquirer can be loaded in the terminal. 


e Verify the integrity of the loaded software. 


When both tests are successful, the terminal shall notify the party loading the 
software whether the load was successfully performed or not. 


To facilitate ICC application upgrade from one version to another, the terminal 
should be able to support at least two versions of the ICC application, as 
identified by the terminal’s Application Version Numbers. 
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10 Data Management 


The data elements listed in this section shall be initialised in the terminal or 
obtainable at the time of a transaction. (Definitions for these data are in Book 3.) 
Additional data elements may be required for initialisation, such as those 
currently used for magnetic stripe processing. 


Whenever a data element is initialised or updated, data integrity shall be 
assured. 


Data elements resident in the terminal shall be under the control of one of the 
following parties: 


e Terminal manufacturer: For example, IFD Serial Number 
e Acquirer (or its agent): For example, Merchant Category Code 


e Merchant: For example, Local Date and Local Time (these may be controlled 
by either the merchant or acquirer) 


The terminal should be constructed in such a way that the data which is under 
control of the acquirer is only initialised and updated by the acquirer (or its 
agent). 


10.1 Application Independent Data 


The terminal resident application independent data elements identified in this 
section shall be initialised in and obtainable from the terminal prior to the 
issuance of the GET PROCESSING OPTIONS command in the Initiate 
Application Processing function described in Book 3 section 10.1. The data shall 
not change during the transaction. Any data sent in the authorisation request 
message shall have the same value as that provided to the card as listed in the 
PDOL (if present) and CDOLI, including Local Date and Local Time if 
appropriate. 
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10.1.1 Terminal Related Data 


The following data elements are application independent and shall be unique to 
the terminal (see section 5.3 for different terminal configurations): 


e IFD Serial Number 

e Local Date 

e Local Time 

e Terminal Country Code 

e Transaction Sequence Counter 


The terminal shall have parameters initialised so that it can identify what 
language(s) are supported to process the card’s Language Preference (see 
section 11.1). 


10.1.2 Transaction Related Data 


The following data elements are application independent and may be specific to 
each device constituting the terminal, such as a host concentrating a cluster of 
devices (see Figure 2 for an example): 


e Additional Terminal Capabilities 
e Terminal Capabilities 
e Terminal Type 


The terminal shall be constructed in such a way that these data objects cannot be 
modified unintentionally or by unauthorised access. 


These data objects may be varied on a transaction by transaction basis which 
means that for each transaction, the terminal may invoke a different value for 
these data objects based on certain characteristics and parameters of the 
transaction (selection criteria). Support of this functionality is optional for the 
terminal. The implementation of this functionality is left to the discretion of the 
terminal manufacturer and is outside the scope of EMV. 
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10.2 Application Dependent Data 


The following data elements are application dependent and, if required, are 
specified by individual payment system specifications: 


Data Elements 


Acquirer Identifier 


Notes 


Application Identifier (AID) 


Application Version Number 


Certification Authority Public Key 

e Certification Authority Public Key 
Exponent 

e Certification Authority Public Key 
Modulus 


Required if terminal supports offline 
data authentication and/or offline PIN 
encipherment. 


See Book 2. 


Certification Authority Public Key 
Index 


Required if terminal supports offline 
data authentication and/or offline PIN 
encipherment: The key index in 
conjunction with the Registered 
Application Provider Identifier (RID) of 
the payment system AID identifies the 
key and the algorithm for offline data 
authentication and/or PIN 
encipherment. 


See Book 2. 


Default Dynamic Data Authentication 
Data Object List (DDOL) 


Required if terminal supports DDA or 
CDA. 


Default Transaction Certificate Data 
Object List (TDOL) 


If not present, a default TDOL with no 
data objects in the list shall be 
assumed. 


Maximum Target Percentage to be 
used for Biased Random Selection 


Required if offline terminal with online 
capability. 


Merchant Category Code 


Merchant Identifier 


Merchant Name and Location 


Table 7: Application Dependent Data Elements 
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Data Elements Notes 
Target Percentage to be used for Required if offline terminal with online 
Random Selection capability. 
Terminal Action Code - Default Required if non-zero values to be used & 


Terminal Action Code - Denial 
Terminal Action Code - Online 


Terminal Floor Limit Required if offline terminal or offline 
terminal with online capability. 


Terminal Identification 


Terminal Risk Management Data If required by individual payment 
system rules. 

Threshold Value for Biased Random Required if offline terminal with online 

Selection capability. 


Transaction Currency Code 


Transaction Currency Exponent 


Transaction Reference Currency Code 


Transaction Reference Currency 
Conversion 


Transaction Reference Currency 
Exponent 


Table 7: Application Dependent Data Elements, continued 


The terminal shall provide the necessary logical key slots to handle the active 
and future replacement Certification Authority Public Keys necessary for data 
authentication and/or offline PIN encipherment. Each logical key slot shall 
contain the following data: RID, Certification Authority Public Key Index, and 
Certification Authority Public Key. 


When the Certification Authority Public Key is loaded to the terminal, the 
terminal shall verify the Certification Authority Public Key Check Sum to detect 
a key entry or transmission error. This checksum is calculated using the 
terminal-supported Secure Hash Algorithm. If the verification process fails, the 
terminal shall not accept the Certification Authority Public Key and, if operator 
action is needed, the terminal shall display an error message. After the 
Certification Authority Public Key is successfully loaded, the terminal should 
store the Certification Authority Public Key Check Sum. 


6 According to Book 3, the default value consists of all bits set to 0, although the ‘Data 
authentication was not performed’, ‘SDA failed’, ‘DDA failed’ and ‘CDA failed’ bits are 
strongly recommended to be set to 1 in the Terminal Action Code - Default and Terminal 
Action Code - Online. 
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Note: alternative integrity verification techniques may be used. The integrity of the 
stored Certification Authority Public Keys should be verified periodically. 


A means for updating data elements specific to payment system applications 
shall be supported wherever this is not in conflict with national legal restrictions. 
Data update may be facilitated from a remote site over a network or locally. 
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Part IV 


Cardholder, Attendant, and 
Acquirer Interface 
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11 Cardholder and Attendant Interface 


11.1 Language Selection 


The terminal shall support at least the local language which is the language of 
common usage in the terminal’s locality or region. To display the standard 
messages defined in section 11.2, the terminal shall support the common 
character set as defined in Annex B, and should support the relevant character 
set defined in the corresponding part of ISO/IEC 8859 when necessary. 


Depending on the local environment and business conditions, the terminal should 
support multiple languages for displaying the set of messages described in 
section 11.2 to the cardholder. A terminal supporting multiple languages may 
need additional parts of ISO/IEC 8859 to display characters relevant to these 
languages. 


ISO/IEC 8859 consists of several parts, each part specifying a set of up to 191 
characters coded by means of a single 8-bit byte. Each part is intended for use for 
a group of languages. All parts of ISO/IEC 8859 contain a common set of 95 
characters, coded between '20' (hexadecimal) and '7E' (hexadecimal) as shown in 
Annex B. This common character set allows the terminal to display Application 
Label(s) and messages in multiple languages using Latin characters without 
using diacritic marks (see example in Annex B). 


If the terminal supports multiple languages, selection of the language to be used 
for displaying cardholder messages is performed prior to the issuance of the GET 
PROCESSING OPTIONS command; otherwise the local language is used to 
display cardholder messages. Language selection may be performed either by 
using the EMV language selection process (based on language preference 
indicated by the card), or by using a proprietary process. 


If the EMV language selection process is used, the following rules apply: 


e Ifthe card does provide a Language Preference data object, the terminal shall 
compare the card’s language preferences with the languages it supports: 


« Ifa match is found, the language with the highest preference shall be used 
for the messages displayed to the cardholder. (The Language Preference 
data object is coded so that the language with the highest preference 
appears first and the lowest preference appears last.) 


« Ifno match is found, the terminal shall allow the cardholder to select their 
preferred language if it has a means for allowing such selection. Messages 
shall be displayed to the cardholder in the selected language or, if the 
terminal has no means of offering language selection to the cardholder, in 
the local language. 


November 2011 Page 87 


11 Cardholder and Attendant Interface EMV 4.3 Book 4 
11.2 Standard Messages7F Cardholder, Attendant, and Acquirer 
Interface Requirements 


e Ifthe card does not provide a Language Preference data object, the terminal 
shall allow the cardholder to select their preferred language if it has a means 
for allowing such selection. Messages shall be displayed to the cardholder in 
the selected language or, if the terminal has no means of offering language 
selection to the cardholder, in the local language. 


Alternatively terminals may support a proprietary language selection process 
which is outside the scope of EMV. If such a proprietary language selection 
process is used, the EMV language selection process shall not be performed. The 
language selected using the proprietary process shall be used throughout the 
transaction. 


Messages should be displayed to the attendant in the language of the attendant’s 
choice or, if the terminal has no means of offering language selection to the 
attendant, in the local language. Messages displayed to the attendant and 
cardholder may be displayed in different languages if supported by the terminal. 


11.2 Standard Messages’ 


To ensure consistency in the messages displayed by the terminal and the PIN 
pad, the following set of messages (or their equivalent meaning) shall be used in 
the languages of preference for the cardholder and attendant. 


The messages shall be uniquely identified by a two-character message identifier 
as shown below. The message identifier is for identification purposes only and is 
not to be displayed to the cardholder or attendant. 


e Values '01'— '13' (hexadecimal) are described in Table 8. 


e Values '14'— '3F' (hexadecimal) are reserved for assignment according to this 
specification. 


e Values '40' —'7F' (hexadecimal) are reserved for use by the individual payment 
systems. 


e Values '80' — 'BF' (hexadecimal) are reserved for use by acquirers. 
e Values 'CO'—'FF' (hexadecimal) are reserved for use by issuers. 
There may be additional messages displayed for the attendant or cardholder. 


Note: Messages may be displayed simultaneously, such as ‘Incorrect PIN’ and ‘Enter 
PIN’. 


7 This specification does not imply that the terminal shall support a set of standard 
messages in English. 
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Message Identifier 
'O \' 


Message 
(AMOUNT) 


Definition 


Indicates the transaction amount to 
both the cardholder and attendant. 


'02' 


'03' 


(AMOUNT) OK? 


APPROVED 


Invites a response from the cardholder 
indicating agreement or disagreement 
with the displayed transaction amount. 
Agreement or disagreement should be 
denoted by pressing the 'Enter' or 
'‘Cancel' keys, respectively. 


Indicates to the cardholder and 
attendant that the transaction has been 
approved. 


'0A' 


CALL YOUR 
BANK 


Indicates to the cardholder or attendant 
to contact the issuer or acquirer, as 
appropriate, such as for voice referrals. 


'O5' 


CANCEL OR 
ENTER 


When used with the ‘ENTER PIN’ 
message, instructs the cardholder to 
validate PIN entry by pressing the 
'Enter' key or to cancel PIN entry by 
pressing the 'Cancel' key. 


'06' 


CARD ERROR 


Indicates to the cardholder or attendant 
a malfunction of the card or a 
non-conformance to answer-to-reset. 


'0O7' 


DECLINED 


Indicates to the cardholder and 
attendant that the online or offline 
authorisation has not been approved. 


'Os' 


'909' 


ENTER 
AMOUNT 


ENTER PIN 


Instructs the cardholder at an 
unattended terminal or the attendant at 
an attended terminal to enter the 
amount of the transaction. Confirmation 
or cancellation of amount entry should 
be denoted by pressing the 'Enter' or 
‘Cancel’ keys, respectively. 


Invites the cardholder to enter the PIN 
for the first and subsequent PIN tries. 
An asterisk is displayed for each digit of 
the PIN entered. 


Table 8: Standard Messages 
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Message Identifier 
'OA' 


Message 


INCORRECT 
PIN 


Definition 


Indicates that the PIN entered by the 
cardholder does not match the reference 
PIN. 


'‘OB' 


'OC' 


INSERT CARD 


NOT 
ACCEPTED 


Instructs to insert the ICC into the IFD. 
Correct insertion should be noted by 
displaying the message ‘PLEASE WAIT’ 
to reassure the cardholder or attendant 
that the transaction is being processed. 


Indicates to the cardholder and 
attendant that the application is not 
supported or there is a restriction on the 
use of the application; for example, the 
card has expired. 


'OD' 


PIN OK 


Indicates that offline PIN verification 
was successful. 


'OE' 


PLEASE WAIT 


Indicates to the cardholder and 
attendant that the transaction is being 
processed. 


'OF' 


PROCESSING 
ERROR 


Displayed to the cardholder or 
attendant when the card is removed 
before the processing of a transaction is 
complete, or when the transaction is 
aborted because of a power failure, or 
when the system or terminal has 
malfunctioned, such as communication 
errors or time-outs. 


'10' 


REMOVE CARD 


Instructs to remove the ICC from the 
IFD. 


a Bebe 


V9! 


USE CHIP 
READER 


USE MAG 
STRIPE 


Instructs to insert ICC into the IC 
reader of the IFD, when the IC and 
magnetic stripe readers are not 
combined. 


Instructs to insert ICC into the 
magnetic stripe reader of the terminal 
after IC reading fails, when the IC and 
magnetic stripe readers are not 
combined. 


'13' 


TRY AGAIN 


Invites the cardholder to re-execute the 
last action performed. 


Table 8: Standard Messages, continued 
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11.3 Application Selection 


A terminal shall support application selection using the ‘List of AIDs’ method as 
described in Book 1, section 12.3.3. A terminal may support application selection 
using the payment systems directory as described in Book 1. 


A terminal supporting more than one application should offer the cardholder the 
ability to select an application or confirm the selection proposed by the terminal. 
Applications supported by both the ICC and the terminal shall be presented to 
the cardholder in priority sequence according to the card’s Application Priority 
Indicator, if present, with the highest priority listed first. 


A terminal allowing cardholder selection or confirmation shall create a list of ICC 
applications that are supported by the terminal as described in Book 1 and shall 
display: 


e the Application Preferred Name(s), if present and if the Issuer Code Table 
Index indicating the part of ISO/IEC 8859 to use is present and supported by 
the terminal (as indicated in Additional Terminal Capabilities) 


e otherwise, the Application Label(s), by using the common character set of 
ISO/IEC 8859 (see Annex B) 


A terminal not offering the cardholder the ability to select or confirm a selection 
shall determine those applications supported by both the card and the terminal 
that may be selected without confirmation of the cardholder according to 
Application Priority Indicator, if present. The terminal shall select the 
application with the highest priority from those. 


If the card returns SW1 SW2 other than '9000' in response to the SELECT 
command, indicating that the transaction cannot be performed with the selected 
application: 


e A terminal allowing cardholder selection or confirmation should display the 
‘TRY AGAIN’ message and shall present to the cardholder the list of 
applications supported by both the ICC and the terminal without this 
application. 


e A terminal not offering cardholder selection or confirmation shall select the 
application with the next highest priority among those supported by both the 
ICC and the terminal that may be selected without cardholder confirmation. 


If no application can be selected, the terminal should display the ‘NOT 
ACCEPTED’ message and shall terminate the transaction. 


The application used for the transaction shall be identified on the transaction 
receipt by the partial Application PAN (or the full PAN, if allowed by payment 
system rules) and the AID. 
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11.4 Receipt 


Whenever a receipt is provided, it shall contain the AID in addition to the data 
required by payment system rules. The AID shall be printed as hexadecimal 
characters. 
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12 Acquirer Interface 


12.1 Message Content 


Messages typically flow from the terminal to the acquirer and from the acquirer 
to the issuer. Message content may vary from one link to another, with data 
being added to enrich the message at the acquirer. To enrich the message, the 
acquirer stores static point of transaction data elements ° based on the Merchant 
Identifier and/or the Terminal Identifier. These data elements are implicitly 
referred to by the Merchant/Terminal Identifier(s) and therefore may be absent 
in terminal to acquirer messages.? In the following sections, this implicit 
relationship is indicated by a specific condition: ‘Present if the 
Merchant/Terminal Identifier(s) do not implicitly refer to the (data element)’. 


Message content may also vary due to data requested by the acquirer but not the 
issuer, such as for transaction capture or audit. The ICC stored data elements 
are implicitly known by the issuer !° based on the AID and/or PAN and therefore 
may be absent in acquirer to issuer messages. In the following sections, this 
implicit relationship is indicated by a specific condition: ‘Present if requested by 
the acquirer’. 


Data requirements may differ depending on terminal operational control, which 
is recognised through a specific condition: ‘Present for Terminal Type = xx’. For 
example, Merchant Identifier is provided only for a merchant-controlled terminal 
(Terminal Type = '2x’'). 


An authorisation message shall be used when transactions are batch data 
captured. A financial transaction message shall be used when online data 
capture is performed by the acquirer. An offline advice shall be conveyed within 
batch data capture when supported. An online advice or a reversal message shall 
be transmitted real-time, similarly to an authorisation or financial transaction 
message. 


8 These data elements indicate point of transaction acceptance characteristics that rarely 
change, such as Merchant Category Code, Acquirer Identifier, or Terminal Country Code. 


9 At a minimum, all data listed in the Card Risk Management Data Object Lists and the 
TDOL shall be available at the point of transaction. 


10 These data elements reflect card acceptance conditions and restrictions that rarely 
change, such as Application Interchange Profile, Application Usage Control, or Issuer 
Action Codes. 
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This section describes requirements associated with ICC transactions and 
distinguishes between existing data elements used for magnetic stripe 
transactions and those created specifically for ICC transactions. Data elements 
referred to as existing are those defined in ISO 8583:1987, though actual 
terminal message contents are usually specific to (each of) the acquiring 
system(s) to which the terminal is connected. For ICC transactions, the values of 
all card-originated data contained in acquirer interface messages shall be as read 
from the chip. It is not acceptable to populate the messages partially with data 
read from the chip and partially with data read from the magnetic stripe (if also 
read). 


For informational purposes, Annex C describes an example of converting 
ICC-related and terminal-related data into message data elements. 
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12.1.1 Authorisation Request 


An authorisation request should convey the data elements contained in Table 9 
and Table 10 subject to the specified conditions. 


Table 9 contains the new data elements specifically created for an ICC 
transaction. 


Data Element Condition 


Application Interchange Profile * !! 


Application Transaction Counter * 


ARQC * 

CID The CID does not need to be forwarded 
to the issuer; the presence of this data 
element is defined in the respective 
payment system network interface 
specifications. 

CVM Results 

IFD Serial Number Present if Terminal Identifier does not 
implicitly refer to IFD Serial Number 

Issuer Application Data * Present if provided by ICC in 


GENERATE AC command response 


Terminal Capabilities 


Terminal Type 
TVR * 


p 


Table 9: ICC-specific Authorisation Request Data Elements 


11 Data elements marked with an asterisk are the minimum set of data elements to be 
supported in authorisation request and response messages, as well as clearing messages, 
for ICC transactions. 
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Table 10 contains existing data elements necessary for an ICC transaction. 


Acquirer Identifier Present for Terminal Type = '1x' or '2x' if Merchant 
Identifier or Terminal Identifier does not implicitly 
refer to a single acquirer 


Amount, Other * Present if cashback used for current transaction 
Application Effective Date | Present if in ICC 


Application Expiration Present if not in Track 2 Equivalent Data 
Date 


Application PAN * Present if not in Track 2 Equivalent Data 


Application PAN Sequence | Present if in ICC 

Number * 

Enciphered PIN Data Present if CVM performed is ‘enciphered PIN for 
online verification’ 


Merchant Category Code Present for Terminal Type = '2x' if Merchant 
Identifier or Terminal Identifier does not implicitly 
refer to a single merchant category 


Merchant Identifier Present for Terminal Type = '2x' if Terminal 
Identifier does not implicitly refer to a single 
merchant 


POSEnyMole Oi SOSCSC“~“S~“~“~“~S~S~*S 
[Terminal Country Code* [SSS 
[Terminal ldentifies [SSS 


Transaction Currency 
Code * 
Transaction Date * en: 


Present if Terminal Type = 'x2', 'x3', 'x5', or 'x6' 
Transaction Type * fe 


Table 10: Existing Authorisation Request Data Elements 


12 Data elements marked with an asterisk are the minimum set of data elements to be 
supported in authorisation request and response messages, as well as clearing messages, 
for ICC transactions. 
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12.1.2. Financial Transaction Request 


A financial transaction request should convey the data elements contained in 
Table 11 and Table 12 subject to the specified conditions. 


Table 11 contains the new data elements created specifically for an ICC 
transaction. 


[application Interchange Pome [OO 
[Application Transaction ounter® [SS 
a 


CID The CID does not need to be forwarded 
to the issuer; the presence of this data 
element is defined in the respective 
payment system network interface 
specifications. 


fovnenits i 
implicitly refer to IFD Serial Number 


Issuer Action Code - Denial Present if requested by acquirer 
Issuer Action Code - Online Present if requested by acquirer 


Present if provided by ICC in 
GENERATE AC command response 
7 
Femina Type 
vee 


Unpredictable Number * Present if input to application 
cryptogram calculation 


Table 11: ICC-specific Financial Transaction Request Data Elements 


13 Data elements marked with an asterisk are the minimum set of data elements to be 
supported in authorisation request and response messages, as well as clearing messages, 
for ICC transactions. 
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Table 12 contains existing data elements necessary for an ICC transaction. 


Data Element 


Acquirer Identifier Present for Terminal Type ='1x' or '2x' if 
Merchant Identifier or Terminal Identifier does 
not implicitly refer to a single acquirer 


from authorised amount 


Application PAN Sequence Present if in ICC 

Number * 

Enciphered PIN Data Present if CVM performed is ‘Enciphered PIN 
for online verification’. 


Issuer Country Code Present if requested by acquirer 


Merchant Category Code Present for Terminal Type = '2x' if Merchant 
Identifier or Terminal Identifier does not 
implicitly refer to a single merchant category 


Merchant Identifier Present for Terminal Type = '2x' if Terminal 
Identifier does not implicitly refer to a single 
merchant 


|POSEntryMode | 
|TerminalCountryCode* | 
|TerminalIdentifier | 
[Transaction Amount* | 
| Transaction Currency Code* fo 
|TransactionDate* | 
Present if Terminal Type ='x2', 'x3', 'x5', or 'x6' 

[Transaction Type* | 


Table 12: Existing Financial Transaction Request Data Elements 


14 Data elements marked with an asterisk are the minimum set of data elements to be 
supported in authorisation request and response messages, as well as clearing messages, 
for ICC transactions. 
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12.1.3. Authorisation or Financial Transaction Response 


Authorisation and financial transaction responses should convey the data 
elements contained in Table 13 and Table 14 subject to the specified conditions. 


Table 13 contains the new data elements specifically created for an ICC 
transaction. 


Issuer Authentication Data * 15 | Present if online issuer authentication 
performed 


Issuer Script * Present if commands to ICC are sent by issuer 
e Issuer Script Template 1 
e Issuer Script Template 2 


Table 13: ICC-specific Authorisation or Financial Transaction Response Data 
Elements 


Table 14 contains existing data elements necessary for an ICC transaction. 


Acquirer Identifier Present for Terminal Type = '1x' or '2x' if in 
request message 
Authorisation Code Present if transaction is approved 


[authvintion Rmromse Code 
[Terminal enter ———=d 
[transaction Date ——S= 
[transaction ime =| 


Table 14: Existing Authorisation or Financial Transaction Response Data 
Elements 


15 Data elements marked with an asterisk are the minimum set of data elements to be 
supported in authorisation request and response messages, as well as clearing messages, 
for ICC transactions. 
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12.1.4 Financial Transaction Confirmation 


A financial transaction confirmation should convey the data elements contained 
in Table 15 and Table 16 subject to the specified conditions. 


Table 15 contains the new data elements specifically created for an ICC 
transaction. 


Issuer Script Results Present if script commands to ICC are 
delivered by terminal 


TEorANG fe 


Table 15: ICC-specific Financial Transaction Confirmation Data Elements 


Table 16 contains existing data elements necessary for an ICC transaction. 


Table 16: Existing Financial Transaction Confirmation Data Elements 
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12.1.5 Batch Data Capture 


Batch data capture should convey the data elements contained in Table 17 and 
Table 18 subject to the specified conditions. Message Type is used to distinguish 
between an offline advice and a financial record. 


Table 17 contains the new data elements specifically created for an ICC 
transaction. 


Application Interchange 
Profile * 16 
Application Transaction 
Counter * 


Application Usage Control Present if requested by acquirer 


CID The CID does not need to be forwarded to the 
issuer; the presence of this data element is 
defined in the respective payment system 
network interface specifications. 


CVM List Present if requested by acquirer 
CVM Resul al 


IFD Serial Number Present if Terminal Identifier does not 
implicitly refer to IFD Serial Number 


Issuer Action Code - Default Present if requested by acquirer 
Issuer Action Code - Denial Present if requested by acquirer 
Issuer Action Code - Online Present if requested by acquirer 


Issuer Application Data * Present if provided by ICC in GENERATE AC 
command response 


Issuer Script Results Present if script commands to ICC are delivered 
by terminal 


Terminal Capabilities 
Terminal Type 


TVR * re 


TC/ARQC or AAC * ARQC may be used as TC substitute 


Unpredictable Number * Present if input to application cryptogram 
calculation 


Table 17: ICC-specific Batch Data Capture Data Elements 


16 Data elements marked with an asterisk are the minimum set of data elements to be 
supported in authorisation request and response messages, as well as clearing messages, 
for ICC transactions. 
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Table 18 contains existing data elements necessary for an ICC transaction. 


Data Element 


Acquirer Identifier Present if for Terminal Type ='1x' or '2x' 
Merchant Identifier or Terminal Identifier does 
not implicitly refer to a single acquirer 


Amount, Authorised * 17 Present if final transaction amount is different 
from authorised amount 

Amount, Other * Present if cashback used for current transaction 

Application Effective Date Present if in ICC 


Application Expiration 
Date 


Application PAN Sequence _ | Present if in ICC 
Number * 


Authorisation Code Present if transaction is approved 


Authorisation Response 
Code 


Issuer Country Code Present if requested by acquirer 


Merchant Category Code Present for Terminal Type = '2x' if Merchant 
Identifier or Terminal Identifier does not 
implicitly refer to a single merchant category 


Merchant Identifier Present for Terminal Type = '2x' if Terminal 
Identifier does not implicitly refer to a single 
merchant 


Ee 
[POS ni Maio «| SSCS 
[terminal Counts; Goie®™ |S 
Ee 
[aeanacton Ameunt® —[ 


Table 18: Existing Batch Data Capture Data Elements 


17 Data elements marked with an asterisk are the minimum set of data elements to be 
supported in authorisation request and response messages, as well as clearing messages, 
for ICC transactions. 
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Data Element 


Transaction Currency Present if Merchant Identifier or Terminal 

Code * Identifier does not implicitly refer to a single 
transaction currency accepted at point of 
transaction 


[transaion Tine [| 


Table 18: Existing Batch Data Capture Data Elements, continued 


12.1.6 Reconciliation 


A reconciliation should convey the existing data elements necessary for ICC 
transactions and subject to the specified conditions. 


Acquirer Identifier Present for Terminal Type ='1x' or '2x' if 
Merchant Identifier or Terminal Identifier does 
not implicitly refer to a single acquirer 


Merchant Identifier Present for Terminal Type = '2x' if Terminal 
Identifier implicitly does not refer to a single 
merchant 


Reconciliation Currency Code | Present if Merchant Identifier or Terminal 
Identifier does not implicitly refer to a single 
transaction currency accepted at point of 
transaction 


Transactions Number (per 
transaction type) 
Transactions Amount (per 
transaction type) 


Table 19: Existing Reconciliation Data Elements 
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12.1.7 Online Advice 


An online advice should convey the data elements contained in Table 20 and 
Table 21 subject to the specified conditions. 


Table 20 contains the new data elements specifically created for an ICC 
transaction. 


Application Interchange 
Profile 

Application Transaction 
a 


IFD Serial Number Present if Terminal Identifier does not implicitly 
refer to IFD Serial Number 


Issuer Application Data Present if provided by ICC in GENERATE AC 


command response 


Issuer Script Results Present if script commands to ICC are delivered 
by terminal 


Termin Copies | 
[aerninal Type | 
ve 
[oorans i 


Unpredictable Number Present if input to application cryptogram 
calculation 


Table 20: ICC-specific Online Advice Data Elements 
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Table 21 contains existing data elements necessary for an ICC transaction. 


Data Element Condition 


Acquirer Identifier Present for Terminal Type = '1x' or '2x' if 
Merchant Identifier or Terminal Identifier does 
not implicitly refer to a single acquirer 


Amount, Authorised Present if final transaction amount is different 
from authorised amount 
Application Effective Date Present if in ICC 


Application Expiration Date | Present if not in Track 2 Equivalent Data 


Application PAN Present if not in Track 2 Equivalent Data 


Application PAN Sequence Present if in ICC 
Number 


Authorisation Response Code 


Merchant Category Code Present for Terminal Type = '2x' if Merchant 
Identifier or Terminal Identifier does not 
implicitly refer to a single merchant category 


Merchant Identifier Present for Terminal Type = '2x' if Terminal 
Identifier does not implicitly refer to a single 
merchant 


POS Entry Mode 


Terminal Country Code Present if Terminal Identifier or IFD Serial 
Number does not implicitly refer to a single 
terminal country 


Terminal Identifier 


Track 2 Equivalent Data Present if in ICC 


Transaction Amount 


Transaction Currency Code Present if Merchant Identifier or Terminal 
Identifier does not implicitly refer to a single 
transaction currency accepted at point of 
transaction 


Transaction Date 


Transaction Time Present if Terminal Type = 'x2', 'x3', 'x5', or 'x6' 


Transaction Type 


Table 21: Existing Online Advice Data Elements 
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12.1.8 Reversal 


A reversal should convey the data elements contained in Table 22 and Table 23 
subject to the specified conditions. 


Table 22 contains the new data elements specifically created for an ICC 
transaction. 


Application Interchange 

Profile 

Application Transaction 

Counter 

IFD Serial Number Present if Terminal Identifier does not implicitly 
refer to IFD Serial Number 


Issuer Application Data Present if provided by ICC in GENERATE AC 
command response 

Issuer Script Results Present if script commands to ICC are delivered 
by terminal 


[terminal Type «| 
a 


Table 22: ICC-specific Reversal Data Elements 
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Table 23 contains existing data elements necessary for an ICC transaction. 


Acquirer Identifier Present for Terminal Type ='1x' or '2x' if 
Merchant Identifier or Terminal Identifier does 
not implicitly refer to a single acquirer 


Application Expiration Date | Present if not in Track 2 Equivalent Data 
Application PAN Present if not in Track 2 Equivalent Data 


Application PAN Sequence Present if in ICC 
Number 


Merchant Category Code Present for Terminal Type = '2x' if Merchant 
Identifier or Terminal Identifier does not 
implicitly refer to a single merchant category 


Merchant Identifier Present for Terminal Type = '2x' if Terminal 
Identifier does not implicitly refer to a single 
merchant 


Original Data Elements Present if available at terminal 


Terminal Country Code Present if Terminal Identifier or IFD Serial 
Number does not implicitly refer to a single 
terminal country 


Track 2 Equivalent Data Present if in ICC 
[ransaeton Anout 


Transaction Currency Code Present if Merchant Identifier or Terminal 
Identifier does not implicitly refer to a single 
transaction currency accepted at point of 
transaction 


Transaction Date ee 
Present if Terminal Type ='x2', 'x3', 'x5', or 'x6' 


Table 23: Existing Reversal Data Elements 
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12.2 Exception Handling 


This section describes exception conditions that may occur during real-time 
authorisation, financial transaction, or online advice and the associated actions 
the terminal shall perform. 


In this section, the term ‘authorisation’ applies to authorisation messages as well 
as financial transaction messages. 


12.2.1 Unable to Go Online 


During transaction processing, the terminal may send an authorisation request 
to the acquirer due to at least one of the following conditions: 


e Online-only terminal type 
e Attendant action (for example, merchant suspicious of cardholder) 
e Terminal risk management parameters set by the acquirer 


e Terminal action analysis in comparing TVR with Issuer Action Code - Online 
and Terminal Action Code - Online (see Book 3 section 10.7) 


e Card action analysis via its response to the first GENERATE AC command: 
CID indicates ARQC returned (see Book 3) 


If the terminal is unable to process the transaction online, as described in Book 38, 
the terminal shall compare the TVR with both Terminal Action Code - Default 
and Issuer Action Code - Default to determine whether to accept or decline the 
transaction offline and shall issue the second GENERATE AC command to the 
ICC indicating its decision: 


e Ifthe terminal accepts the transaction, it shall set the Authorisation Response 
Code to ‘Unable to go online, offline accepted’. 


e Ifthe terminal declines the transaction, it shall set the Authorisation 
Response Code to ‘Unable to go online, offline declined’. 


The result of card risk management performed by the ICC is made known to the 
terminal through the return of the CID indicating either a TC for an approval or 
an AAC for a decline. 
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12.2.2 Downgraded Authorisation 


When the authorisation response received by the terminal does not contain the 
Issuer Authentication Data, the terminal shall not execute the EXTERNAL 
AUTHENTICATE command and shall set the ‘Issuer authentication was 
performed’ bit in the Transaction Status Information (TSI) to 0, as described in 
Book 3. The terminal shall continue processing based on the Authorisation 
Response Code returned in the response message as described in section 6.3.6. 


Note: If the acquirer or the intermediate network is unable to support ICC messages, 
the terminal should send messages compliant with current payment system 
specifications. Payment systems will determine compliance requirements for message 
content. 
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12.2.3. Authorisation Response Incidents 


The authorisation response may not be correctly received by the terminal. The 
following incidents may occur: 


e Response not received or received too late (for example, network failure, 
time-out) 


e Response with invalid format or syntax 
e Request not received by the authorisation host (for example, network failure) 


After repeat(s)!8, if any, of the authorisation request, the terminal shall process 
the transaction as being unable to go online. As described in Book 3, the terminal 
shall compare the TVR with both Terminal Action Code - Default and Issuer 
Action Code - Default to determine whether to accept or decline the transaction 
offline and shall issue the second GENERATE AC command to the ICC 
indicating its decision: 


e Ifthe terminal accepts the transaction, it shall set the Authorisation Response 
Code to ‘Unable to go online, offline accepted’. 


e Ifthe terminal declines the transaction, it shall set the Authorisation 
Response Code to ‘Unable to go online, offline declined’. 


The result of card risk management performed by the ICC is made known to the 
terminal through the return of the CID indicating either a TC for an approval or 
an AAC for a decline. 


When online data capture is performed by the acquirer, the terminal shall send a 
reversal message regardless of the final decision on the transaction (to ensure 
that if the authorisation host received a request and sent a response, the 
transaction is cancelled). If the transaction is finally approved offline (TC 
returned by the ICC), the terminal shall create a financial record to be forwarded 
to the acquirer. 


18 Acquirers or networks may require that an authorisation request be repeated in the 
event that a valid response is not obtained. Requirements for such repeat(s) are outside 
the scope of EMV. 
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12.2.4 Script Incidents 


The Issuer Script may not be correctly processed. The following incidents may 
occur: 


e Script length error: The response message contains one (or more) Issuer 
Script(s) whose cumulative total length is larger than the script length 
supported by the network or terminal. 


e Script with incorrect format or syntax: The terminal is unable to correctly 
parse the Issuer Script(s) into single Script Commands, as specified in Book 3. 


If either of these incidents occurs, the terminal shall terminate the processing of 
the Issuer Script in which the incident occurred, shall read if possible the Script 
Identifier (when present) and shall report it as not performed in the Issuer Script 
Results of the financial transaction confirmation or batch data capture message. 
The terminal shall continue processing any subsequent Issuer Script. 


Book 3, Annex E gives some examples of TVR and TSI bit setting following script 
processing. 


12.2.5 Advice Incidents 


If the terminal supports advices but is unable to create an advice when requested 
by the card in the CID returned in the response to the GENERATE AC command 
as described in section 6.3.7, the terminal shall terminate the transaction. 
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Part V 


Annexes 
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Annex A Coding of Terminal Data Elements 


This annex provides the coding for the Terminal Type, Terminal Capabilities, 
Additional Terminal Capabilities, CVM Results, Issuer Script Results, and 
Authorisation Response Code. 


Coding of data (bytes or bits) indicated as RFU shall be '0". 
Neither the terminal nor the card shall check the data indicated as RFU. 


A1 Terminal Type 


| __ Operational Control Provided By: __| | __ Operational Control Provided By: | Provided By: 


Attended 
Online only 
Offline with online capability 
Offline only 

Unattended 


Online only 


Offline with online capability 
Offline only 


Table 24: Terminal Type 


Terminal Types '14', '15', and '16' with cash disbursement capability (Additional 
Terminal Capabilities, byte 1, ‘cash’ bit = 1) are considered to be ATMs. All other 
Terminal Types are not considered to be ATMs. 


19 For the purpose of this specification, an attended cardholder-controlled terminal is 
considered to be a nonexistent category. 
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Examples of terminal types are: 
e Attended and controlled by financial institution: Branch terminal 


e Attended and controlled by merchant: Electronic cash register, portable POS 
terminal, stand-alone POS terminal, host concentrating POS terminal 


e Unattended and controlled by financial institution: ATM, banking automat 


e Unattended and controlled by merchant: Automated fuel dispenser, pay 
telephone, ticket dispenser, vending machine 


e Unattended and controlled by cardholder: Home terminal, personal computer, 
screen telephone, Payphones, Digital interactive Television / Set Top Boxes. 


See Annex E for more detailed examples. 


A2 Terminal Capabilities 


This section provides the coding for Terminal Capabilities: 
e Byte 1: Card Data Input Capability 

e Byte 2: CVM Capability 

e Byte 3: Security Capability 

In the tables: 


e A‘l’ means that if that bit has the value 1, the corresponding ‘Meaning’ 
applies. 


e An ‘x’ means that the bit does not apply. 


pba | Meaning 


Po [mer 


Table 25: Terminal Capabilities Byte 1 - Card Data Input Capability 
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Plaintext PIN for ICC 
verification 

Enciphered PIN for online 
a 


|Signature (paper) | (paper) 


Enciphered PIN for offline 
verification 


Table 26: Terminal Capabilities Byte 2 - CVM Capability 


If the terminal supports a CVM of signature, the terminal shall be an attended 
terminal (Terminal Type = 'x1', 'x2', or 'x3') and shall support a printer 
(Additional Terminal Capabilities, byte 4, ‘Print, attendant’ bit = 1). 


FaCcr an 
[eer 


Po [mer 


Table 27: Terminal Capabilities Byte 3 - Security Capability 
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A3 Additional Terminal Capabilities 


This section provides the coding for Additional Terminal Capabilities: 
e Byte 1: Transaction Type Capability 

e Byte 2: Transaction Type Capability 

e Byte 3: Terminal Data Input Capability 

e Byte 4: Terminal Data Output Capability 

e Byte 5: Terminal Data Output Capability 

In the tables: 


e A‘l’ means that if that bit has the value 1, the corresponding ‘meaning’ 
applies. 


e An ‘x’ means that the bit does not apply. 


a 
Px [cesoack 


Table 28: Add’l Term. Capabilities Byte 1 - Transaction Type Capability 


20 For the purpose of this specification, an inquiry is a request for information about one 
of the cardholder’s accounts. 


21 For the purpose of this specification, a transfer is a movement of funds by a cardholder 
from one of its accounts to another of the cardholder’s accounts, both of which are held by 
the same financial institution. 


22 For the purpose of this specification, a payment is a movement of funds from a 
cardholder account to another party, for example, a utility bill payment. 
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aN eo es 

bi bl 
characters keys 

| Commend ag 

Pac [Rincon ess 

Po [Ree 


Table 30: Add’l Term. Capabilities Byte 3 - Terminal Data Input Capability 


23 A cash deposit is considered to be a transaction at an attended or unattended terminal 
where a cardholder deposits cash into a bank account related to an application on the 
card used. 
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Table 31: Add’l Term. Capabilities Byte 4 - Term. Data Output Capability 


The code table number refers to the corresponding part of ISO/IEC 8859. 


rc 
Pa [cots tabie? 


Table 32: Add’l Term. Capabilities Byte 5 - Term. Data Output Capability 


The code table number refers to the corresponding part of ISO/IEC 8859. 


24 Tf the terminal is attended (Terminal Type = ‘x1’, ‘x2’, or ‘x3’) and there is only one 
printer, the ‘Print, attendant’ bit shall be set to ‘1’ and the ‘Print, cardholder’ bit shall be 
set to ‘0’. 


If the terminal is attended and there is only one display, the ‘Display, attendant’ bit shall 
be set to ‘1’ and the ‘Display, cardholder’ bit shall be set to ‘0’. 


If the terminal is unattended (Terminal Type = ‘x4’, ‘x5’, or ‘x6’), the ‘Print, attendant’ 
and ‘Display, attendant’ bits shall be set to ‘0’. 
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A4 CVM Results 


Byte 1 CVM Performed Last CVM of the CVM List actually performed by 
the terminal: One-byte CVM Code of the CVM 
List as defined in Book 38 (‘3F" if no CVM is 
performed) 

Byte 2 CVM Condition One-byte CVM Condition Code of the CVM List 
as defined in Book 3 or ‘00’ if no actual CVM was 
performed 

Byte 3 CVM Result Result of the (ast) CVM performed as known by 
the terminal: 

'0' = Unknown (for example, for signature) 

'1' = Failed (for example, for offline PIN) 

'2'= Successful (for example, for offline PIN) 
or set to ‘1’ if no CVM Condition Code was 
satisfied or if the CVM Code was not recognised 
or not supported 

Table 33: CVM Results 
A5 Issuer Script Results 
Byte 1 Script Most significant nibble: Result of the Issuer Script 
Result processing performed by the terminal: 
"0 = Script not performed 
ei = Script processing failed 
'2' = Script processing successful 
Least significant nibble: Sequence number of the Script 
Command 
‘0' = Not specified 
'l'to'E' =Sequence number from 1 to 14 
oR = Sequence number of 15 or above 
Bytes Script Script Identifier of the Issuer Script received by the 
2-5 Identifier terminal, if available, zero filled if not. Mandatory if 
more than one Issuer Script was received by the 
terminal. 


Table 34: Issuer Script Results 


Bytes 1-5 are repeated for each Issuer Script processed by the terminal. 
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A6~ Authorisation Response Code 


When transmitted to the card, the Authorisation Response Code obtained from 
the authorisation response message shall include at least the following: 


e Online approved 

e Online declined 

e Referral (initiated by issuer) 
e Capture card 


In addition, the terminal shall be able to generate and transmit to the card the 
new response codes listed in Table 35 when transactions are not authorised 
online: 


Authorisation Response Code Value 
Offline approved Y1 
Offline declined Z1 
Unable to go online, offline approved Y38 
Unable to go online, offline declined Z3 


Table 35: Authorisation Response Codes 


The terminal shall never modify the Authorisation Response Code returned in 
the response message.?5 


25 The card’s final decision is reflected in the Cryptogram Information Data and not in the 
Authorisation Response Code. 
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Annex B Common Character Set 


Table 36 shows the character set common to all parts of ISO/IEC 8859: 


Table 36: Common Character Set 
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The following is an example of the use of the common character set to display the 
‘APPROVED’ message in French without supporting the part of ISO/IEC 8859 
that allows the relevant diacritic marks to be displayed. 


If the terminal supports Part 1 of ISO/IEC 8859 (the Latin 1 alphabet) and 
supports the display of the standard messages in French, when a card indicates 
in its Language Preference that French is the preferred language, the terminal 
can display the ‘APPROVED’ message as ‘ACCEPTE’, using the appropriate 
diacritic marks. 


If the terminal does not support Part 1 of ISO/IEC 8859 (the Latin 1 alphabet) 
but supports Part 8 (the Hebrew alphabet), the terminal is still able to support 
the display of the standard messages in French by using the common character 
set. When a card indicates in its Language Preference that French is the 
preferred language, the terminal can display the ‘APPROVED’ message as 
‘ACCEPTE’, without the use of diacritic marks. The cardholder should be able to 
comprehend the message. 
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Annex C Example Data Element Conversion 


For the data elements listed in section 12.1, Table 37 illustrates an example of 
the relationship between: 


e the ICC-related data described in Book 3 and the terminal-related data 
described in this specification 


e the data transmitted in messages as defined in ISO 8583:1987 and bit 55 from 
ISO 8583:1993 


This does not imply that ISO 8583 is required as the message standard. 


ICC Data Bt Message Data Name 


'9F01' | Acquirer Identifier Acquiring Institution 
Identification Code 

'9F02' | Amount, Authorised Amount, Transaction 

or '81' (authorisation) 
Amount, Original Transaction 


(batch data capture, financial 
transaction) 


anit 


'9F26' | Application Cryptogram ICC System-Related Data 
'5F25' | Application Effective Date Date, Effective (YYMM only) 
'5F24' | Application Expiration Date es Date, Expiration (YYMM only) 


'82' | Application Interchange ICC System-Related Data 
Profile 


Application PAN 


'5F34' | Application PAN Sequence 2 zn Number 
Number 

'9F36' | Application Transaction ICC System-Related Data 
Counter 


'9F07' | Application Usage Control ICC System-Related Data 


Table 37: Data Element Conversion 
Note: Only defined in ISO 8583:1993 
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ICC Data Message Data Name 


Authorisation Code EL Identification 
Response 


'9F27' | Cryptogram Information Data ICC System-Related Data 


'9F34' | CVM Results act System-Related Data 
Enciphered PIN Data | 52 |PIN Data 


'9F1E' | IFD Serial Number see note | Card Accepting Device (CAD) 
Management 


Ea 
a <] 
| 55 
am 
| 85 
| 20 | 
atest lil hanna 
— 
al 
ae 
| 2 
| 22 
za 


Table 37: Data Element Conversion, continued 


Note: Only defined in additional/private data element of ISO 8583:1987 or 
ISO 8583:1993 
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ICC Data | Bit | Message Data Name 


Terminal Country Code 19 Acquiring Institution Country 
Code 


Card Acceptor Name/Location 
(af terminal/acquirer countries 
are different) 


'9F1C' | Terminal Identification 41 Card Acceptor Terminal 
Identification 


Track 2 Equivalent Data Track 2 Data 


ee ee ee 
(MMDD only) 


'9F37' | Unpredictable Number ICC System-Related Data 


Table 37: Data Element Conversion, continued 


Note: Only defined in additional/private data element of ISO 8583:1987 or 
ISO 8583:1993 


November 2011 Page 127 


EMV 4.3 Book 4 12 Acquirer Interface 
Cardholder, Attendant, and Acquirer 12.2 Exception Handling 
Interface Requirements 


Annex D Informative Terminal Guidelines 


D1 Terminal Usage 


Because terminals are installed in a variety of environments and locations, it is 
recognised that throughout the world different attempts have been made to 
group relevant guidelines into different categories: 


e Climatic conditions where the terminal is used (climate controlled, outdoor, 
indoor) 


e Mechanical conditions (such as vibration, shocks, drop-tests) 
e Electronic restrictions (such as isolation, security, penetration) 


The guidelines have been documented in industry standards established in 
Europe and the United States (see Annex D5 for informative references). 


D2 Power Supply 


D2.1 External Power Supply 


The power supply provides the required voltage and current to all components of 
the terminal. The power supply should comply with the relevant national safety 
regulations. 


D2.2 Battery Requirements 


An internal battery is used to prevent loss of sensitive data residing in the 
terminal in case of power supply breakdown. 


For portable terminals, the battery supports necessary terminal functions (see 
Book 1 for power/current requirements). 


Power consumption can be reduced by energising the terminal automatically at 
card insertion. 
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D3 Keypad 


To prevent characters printed on the keys of the keypad from becoming illegible 
after a while, precautions should be taken so that they: 


e have wear-resistant lettering 


e are able to function in normal operating environment including resistance to 
soft drink spills, alcohol, detergents, gasoline, etc. 


e when operated as outdoor terminals, can resist the temperature ranges 
commonly encountered 


D4 Display 


To cater for visually disabled people, characters on the display are visible in all 
lighting conditions (bright overhead or dim diffuse light) and the size of the 
characters is large enough to be read from a distance of 1 meter. 


D5 __siInformative References 


IEC 950:1991 Safety of information technology equipment, including 
electrical business equipment, second edition. 
(Amendment 1-1992) (Amendment 2-1998) 


IEC 801-2:1991 Electromagnetic compatibility for industrial-process 
measurement and control equipment — 
Part 2: Electrostatic discharge requirements, second 
edition 


IEC 802-3:1984 Electromagnetic compatibility for industrial-process 
measurement and control equipment — 
Part 3: Radiated electromagnetic field requirements, 
first edition 


IEC 801-4:1988 Electromagnetic compatibility for industrial-process 
measurement and control equipment — 
Part 4: Electrical fast transient/burst requirements, 
first edition 


IEC 68-2-5:1975 Basic environmental testing procedures — 
Part 2: Tests — test Sa: Simulated solar radiation at 
ground level, first edition 
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IEC 68-2-6:1982 


IEC 68-2-11:1981 


IEC 68-2-27:1987 


IEC 68-2-32:1975 


EN 60-950:1988 


EN 41003:1993 


UL 1950:19938 


NF C 20-010:1992 
NF C 98-310:1989 


NF C 98-020:1986 


Basic environmental testing procedures — 

Part 2: Tests — test Fc and guidance: Vibration 
(sinusoidal), fifth edition. (Amendment 1: 1983) 
(Amendment 2: 1985) 


Basic environmental testing procedures — 
Part 2: Tests — test Ka: Salt mist, third edition 


Basic environmental testing procedures — 

Part 2: Tests — Guidance for damp heat tests, third 
edition 

Basic environmental testing procedures — 

Part 2: Tests — test Ed: Free fall, second edition. 
(Amendment 2-1990 incorporating Amendment 1) 


Safety of information technology equipment including 
electrical business equipment 


Particular safety requirements for equipment to be 
connected to telecommunication networks 


Safety of information technology equipment including 
electrical business equipment 


Degrees of protection provided by enclosure (IP code) 
Financial transaction terminals 2° 


Telephone and telematic equipment. Electromagnetic 
compatibility 


26 This standard applies only to stand-alone terminals. 
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Annex E Examples of Terminals 


For informational purposes only, this annex provides some examples of the 
physical and functional characteristics of terminals. Each example describes the 
setting of Terminal Type, Terminal Capabilities, and Additional Terminal 
Capabilities according to the specific terminal characteristics. This annex does 
not establish any requirements as such. 
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E1 Example 1 - POS Terminal or Electronic Cash 
Register 


Ee (a 
function keys) + PIN pad 
One for cardholder 

Functional | 


Table 38: Example of POS Terminal or Electronic Cash Register 


The coding of the terminal-related data for this example is the following: 
e Terminal Type = '22' 


e Terminal Capabilities, byte 1 ='EO' (hexadecimal) 
byte 2 = 'AO' (hexadecimal) 
byte 3 ='CO' (hexadecimal) 


e Additional Terminal Capabilities, byte 1 ='50' (hexadecimal) 
byte 2 = '00' (hexadecimal) 
byte 3 = 'BO' (hexadecimal) 
byte 4 = 'BO' (hexadecimal) 
byte 5 ='01' (hexadecimal) 
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E2 Example 2-ATM 


[Characteristics «SSCS ample? 
La 
Buscema id) 


Table 39: Example of ATM 


The coding of the terminal-related data for this example is the following: 
e Terminal Type ='14' 


e Terminal Capabilities, byte 1 ='60' (hexadecimal) 
byte 2 = '40' (hexadecimal) 
byte 3 ='20' (hexadecimal) 


e Additional Terminal Capabilities, byte 1 ='8E' (hexadecimal) 
byte 2 = '00' (hexadecimal) 
byte 3 = 'BO' (hexadecimal) 
byte 4 = '50' (hexadecimal) 
byte 5 = '05' (hexadecimal) 
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E3 Example 3 - Vending Machine 


[Characteristics =< SSC ample 
a 
Fee 


Table 40: Example of Vending Machine 


The coding of the terminal-related data for this example is the following: 
e Terminal Type = '26' 


e Terminal Capabilities, byte 1 ='60' (hexadecimal) 
byte 2 = '00' (hexadecimal) 
byte 3 ='CO' (hexadecimal) 


e Additional Terminal Capabilities, byte 1 ='40' (hexadecimal) 
byte 2 = '00' (hexadecimal) 
byte 3 ='10' (hexadecimal) 
byte 4 = '00' (hexadecimal) 
byte 5 = '00' (hexadecimal) 
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